The use-related risk analysis (URRA) links user tasks, possible use errors, hazardous situations and potential harm into a continuous chain. It is the central bridge between usability engineering and risk management, the place where the design decision and the risk assessment of a medical device meet.
The chain from task to harm
The URRA follows a fixed chain of reasoning that is worked through for every user task identified in the task analysis: Which use errors are plausible for this task? Can such an error lead to a hazardous situation? And what harm could result from it for the patient, user or third parties?
This chain is deliberately built so that each step must be justified from the previous one. A potential for harm without a comprehensible triggering mechanism is just as unreliable as a use error whose consequence is never thought through to the end. Only the complete chain makes visible which tasks are actually safety-relevant and which, however unpleasant an error there would be, remain without consequences for patient safety.
The same chain also applies to packaging interactions: If a sterile product touches a non-sterile surface during opening, this is a use error originating in packaging usability that can lead to an infection via the hazardous situation “contaminated product is made available”. Such use-related risks belong in the URRA just as much as errors on the actual operating interface.
Structure of a URRA in practice
In practice, the URRA is usually kept in tabular form, with one row per identified use error and columns for the task involved, the error description, the resulting hazardous situation, the severity of harm, intended risk control measures and, where applicable, a reference to evidence with which the effectiveness of selected risk control measures was assessed.
The assessment typically also takes into account the severity of the respective possible harm according to the evaluation criteria defined in risk management. The URRA thus serves not only to identify errors but also to prioritize risk control measures.
This structure is not an end in itself: It ensures that every row of the URRA can ultimately be traced back to concrete evidence: either to a design measure whose effectiveness was tested in the summative evaluation or to a justified assessment of why a residual risk is acceptable. A URRA that merely lists errors without providing this traceability does not fulfill its actual purpose.
Two sources that must be brought together
A robust URRA draws on two complementary sources that each have blind spots on their own. The project-internal analysis, building on task analysis, workflow analysis and the perception-cognition-action model, provides a concrete interaction model but can overlook product-specific error patterns that are not known to the development team.
The external research (findings from post-market surveillance, from known usability problems of comparable products and from incident databases) provides real error patterns but, without a concrete interaction model, often leads to vague statements that are difficult to test. Only the combination of both perspectives makes the URRA robust: The internal analysis gives the external finding a concrete place in the workflow, and the external finding protects the internal analysis from blind spots.
A detailed practical guide to deriving hazard-related use scenarios from both sources can be found in the in-depth article “Identification of hazard-related use scenarios” in our knowledge base.
From the URRA to critical tasks
The URRA is the basis from which hazard-related use scenarios and critical tasks are derived. A task is considered critical if a use error can lead to serious harm. Existing risk control measures reduce the risk but change nothing about this classification. The chain of task, use error, hazardous situation and harm documented in the URRA thus provides the basis for identifying critical tasks, not automatically the finished list. In the FDA environment, critical tasks are often derived from the analyzed risks. IEC 62366-1, by contrast, focuses on hazard-related use scenarios that are selected for the summative evaluation.
This derivation decides the scope of the summative evaluation: Critical tasks must be tested there. A URRA that does not identify a safety-relevant task as critical therefore has a direct consequence: The validation then does not test what actually would have to be tested, and a real risk remains undetected.
A living document, not a one-off product
A frequent shortcoming in practice: The URRA is created early in the project and not updated afterwards, although design, context of use or findings from tests change over the course of the project. Every design change, every finding from a formative evaluation and every new insight from post-market surveillance of predecessor products should flow back into the URRA.
Equally important is the feedback after the summative evaluation: Observed, previously unknown use errors must be included in the URRA and assessed, even if the product has formally already passed validation. The URRA does not end with approval but is continued through post-market surveillance across the entire product lifecycle.
Regulatory reference
IEC 62366-1 does not prescribe a URRA as a separate document but requires that use-related hazards, hazardous situations and hazard-related use scenarios be identified. The URRA is a common tool for this and at the same time the point at which the usability engineering process is interlinked with risk management according to ISO 14971. Use errors and their consequences must therefore appear consistently in both documentations.
In FDA submissions, the analysis of use-related risks is often documented in tabular form to ensure traceability between risks, critical tasks and validation activities. The FDA human factors guidance does not prescribe a specific table structure and requires that the critical tasks derived from it be reflected in the test plan of the human factors validation. For the EU Medical Device Regulation (MDR), the URRA is the basis for demonstrating in a comprehensible way the reduction of risks from use errors required in Annex I.
The use-related risk analysis links tasks, use errors, hazardous situations and harm into a continuous, comprehensible chain and is thus the bridge between usability engineering and risk management.
It becomes robust only through the combination of project-internal analysis and external research, and it remains effective only if it is kept up to date across the entire product lifecycle.
Frequently asked questions (FAQ)
What is the difference between the URRA and the risk management file according to ISO 14971?
The URRA focuses on use-related risks and provides the application-specific perspective; the risk management file according to ISO 14971 considers all types of risk of a product, technical as well as use-related. Both must refer to each other consistently. Use errors and their consequences must not be assessed contradictorily in the two documents.
Where do the use errors considered in the URRA come from?
From two complementary sources: the project-internal analysis based on task analysis and interaction model, and the external research on known usability problems and incidents of comparable products. Both sources together provide a more robust picture than either on its own.
Does the URRA have to be continued after approval?
Yes. New findings from post-market surveillance, for example previously unknown use errors, must be included in the URRA and assessed. It is a living document across the entire product lifecycle, not a release document created once.
What happens if a safety-relevant task is overlooked in the URRA?
It is then also not classified as a critical task and accordingly does not flow into the testing scope of the summative evaluation. A real risk would thus remain undetected, one reason why the completeness of the underlying task analysis is so important for the URRA.
Do you need a use-related risk analysis that holds up equally before a notified body (the EU conformity assessment body) and the FDA? We interlink usability engineering and risk management for you consistently.
More about our usability engineeringSources
- IEC 62366-1:2015+AMD1:2020, Medical devices, Part 1: Application of usability engineering to medical devices
- ISO 14971:2019, Medical devices, Application of risk management to medical devices
- Regulation (EU) 2017/745 on medical devices (MDR)
- FDA Guidance: Applying Human Factors and Usability Engineering to Medical Devices