---
title: Risk Management and Usability Engineering Under MDR
description: How risk management and usability engineering connect under MDR: use-related risks bridge EN ISO 14971 and EN 62366-1 for startups.
authors: Tibor Zechmeister, Felix Lenhard
category: Risk Management Under MDR
primary_keyword: risk management usability engineering MDR
canonical_url: https://zechmeister-solutions.com/en/blog/risk-management-usability-engineering-link
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# Risk Management and Usability Engineering Under MDR

*By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.*

> **Use-related risks are the bridge between EN ISO 14971:2019+A11:2021 and EN 62366-1:2015+A1:2020. Under MDR Annex I §5 and §22, use errors must be reduced as far as possible through safe design, not written off as a training problem. Tibor's Q7 lesson: training is never a substitute for engineered-out use errors.**

**By Tibor Zechmeister and Felix Lenhard.**

## TL;DR
- Usability engineering and risk management are not parallel tracks. They share the same hazards, the same risks, and the same control hierarchy.
- EN ISO 14971:2019+A11:2021 defines the risk management process. EN 62366-1:2015+A1:2020 defines the usability engineering process. The bridge between them is the hazard-related use scenario.
- MDR Annex I §5 and §22 require manufacturers to reduce risks from ergonomic features and user characteristics as far as possible, including for users with training, impairment, or no prior experience.
- Training and labeling are information for safety. They are the lowest tier of the control hierarchy and rarely sufficient on their own.
- Connected devices (app plus hardware) must fold the app into the usability engineering file. An 80-year-old user who cannot configure the app creates the same clinical risk as a physical misuse.

## Why this matters

Tibor has one story that captures the whole topic. A handheld device designed by a left-handed-dominated engineering team. The display was optimised for a left-hand hold. Summative evaluation with right-handed users showed the display appeared upside down. The fix was a software flip for orientation. The lesson was not "left-handers are bad engineers". The lesson was that development teams cannot see what is wrong with their own device without putting it in front of representative users, and the gap between the team's intuition and the user's reality is exactly where use-related risks live.

There is a second story. A tongue-and-mouth controlled wheelchair for quadriplegic patients. During design, the team chose a mouthpiece colour that tested fine indoors. Auditors asked about outdoor use. The chosen colour was the exact colour that attracts bees. A patient using the chair outdoors could be stung on the mouthpiece. The use specification had only covered indoor scenarios. The usability engineering file and the risk management file had not been read against each other.

Felix coaches startups who frequently treat these as two separate paperwork obligations. Usability for EN 62366-1, risk for EN ISO 14971, two files, two owners, two audit trails. That structure guarantees misses. The connection has to be engineered in.

## What MDR actually says

The MDR requires the connection directly.

**MDR Annex I, Chapter I, General Safety and Performance Requirements.** The GSPRs require risks related to use to be reduced as far as possible. The "as far as possible" ratchet applies to use-related risks exactly as it applies to mechanical, biological, or electrical risks. A use error that could have been designed out but was left in, with a warning label as the only control, is a common auditor finding.

**MDR Annex I §5.** Devices shall be designed, manufactured, and packaged in such a way that risks are minimised, including risks from ergonomic features of the device and the environment in which the device is intended to be used, taking into account the technical knowledge, experience, education, training, and use environment, as well as the medical and physical conditions of intended users.

**MDR Annex I §22.** Devices intended for use by lay persons shall be designed and manufactured in such a way that they perform appropriately for their intended purpose, taking into account the skills and the means available to lay users and the influence resulting from variation that can be reasonably anticipated in the lay user's technique and environment.

**EN 62366-1:2015+A1:2020.** The harmonised usability engineering standard. The process starts with the use specification, proceeds through user interface specification, identifies known and foreseeable hazards related to the user interface, produces the hazard-related use scenarios, and runs formative and summative evaluation. The output is the usability engineering file.

**EN ISO 14971:2019+A11:2021.** The risk management process defines hazard, hazardous situation, and harm. Use errors are a source of hazardous situations and therefore a standard input to the risk analysis.

The bridge is built in one direction: every hazard-related use scenario identified in EN 62366-1 is an input to the EN ISO 14971 risk analysis, and every use-related hazard identified in the risk analysis must be reflected in the usability engineering file. The two files cannot contradict each other.

Plain-language translation: the MDR treats use errors as engineering problems first and information problems last.

## A worked example

A Class IIa home-use infusion aid designed for patients with chronic conditions. The team has built a strong risk management file covering mechanical, biological, and electrical hazards. Usability was scoped late, treated as a summative checkbox.

During a pre-submission review, Tibor walks the team through a hazard-related use scenario exercise. The team writes out the full use specification at the granularity he recommends: unboxing, initial setup, first use, routine use, cleaning, storage, travel, emergency stop, and end of life. For each procedure, they list the user actions required, the intended outcome, and the foreseeable deviations.

Under routine use, the team identifies a deviation: the user loads the device in low light and inserts the cartridge backwards. The deviation is physically possible because the cartridge housing accepts both orientations, with different clinical consequences. In the original risk file, this scenario did not exist. The only control was a warning triangle in the IFU and a label on the cartridge itself.

The team runs the hierarchy of controls in the order Tibor teaches:

1. Inherent safety by design. Can the housing be reshaped so the cartridge physically cannot be inserted backwards? Yes, with a keyed insert. Cost: one additional plastic feature on the housing.
2. Protective measures. If the housing change were impossible, a sensor detecting orientation and refusing to start the pump would qualify. More expensive, more code, more verification.
3. Information for safety. The warning triangle and the label. The original approach.

The team picks level one. The risk file is updated. The usability engineering file references the new control. The summative evaluation now tests the scenario in a low-light simulated home environment with representative users, per EN 62366-1:2015+A1:2020. The notified body reviews both files together at the audit.

A second scenario: the connected smartphone app that pairs with the pump. The team had initially scoped the app out of usability because "it is just an app". Tibor flags this per his Q7 from the follow-up interview. An 80-year-old patient who cannot download, install, and configure the app safely creates the same clinical risk as a physical misuse. The team folds the app into the usability engineering file and runs formative testing with representative elderly users. Two UI changes result, both of which would have been missed otherwise.

## The Subtract to Ship playbook

The playbook for founders:

**1. Run one joint kickoff.** The risk lead and the usability lead sit in the same room for the first session. They agree on a single hazard vocabulary and a single use-case vocabulary. Two files can be maintained separately, but the words in them must match. A hazard called "incorrect cartridge orientation" in the risk file cannot be called "wrong insertion" in the usability file. Auditors spot vocabulary drift fast.

**2. Write the use specification at procedure granularity.** Not "the user uses the device". Instead, decompose: unboxing, setup, first use, routine use, edge cases, cleaning, transport, travel, storage, error recovery, emergency stop, end of life. Tibor's Q5 lesson applies: divide and conquer. Every procedure is a scenario. Every scenario is a source of hazards. A use specification that stops at "the user uses the device" hides risks in plain sight.

**3. Map hazard-related use scenarios both ways.** For every use scenario, list foreseeable deviations and the resulting hazardous situations. Feed these into the risk analysis. For every use-related hazard already in the risk file, check that it appears as a use scenario in the usability file. A cross-reference table between the two files is a cheap and highly audit-visible artefact.

**4. Apply the control hierarchy with discipline.** For every use-related risk, explicitly document why a higher-tier control was not feasible before accepting a lower-tier control. MDR Annex I §5 and §22 require this discipline. Tibor's audit finding pattern: teams skip straight to information for safety because the IFU is easier to change than the housing. Auditors catch this.

**5. Never accept "we will train the user".** Training is information for safety. It is the bottom tier of the hierarchy. Training is legitimate as a secondary layer but never as the first response. Tibor's Q7 lesson from the follow-up interview is the hard rule here: training is not a substitute for engineered-out use errors. If the only answer to a use error is "we will train them", the team has not done the work.

**6. Fold connected components into the usability file.** Every app, every accessory, every configuration tool that affects safe use gets a usability engineering file entry. The 80-year-old patient who cannot configure the Bluetooth pairing is a usability hazard under EN 62366-1:2015+A1:2020, not a customer support issue.

**7. Test the IFU, not just the device.** Tibor's Q8 method: during summative, hand the user the device and the IFU with no coaching and no questions. Watch them try to complete the task. If they cannot, the IFU failed, even if the device succeeded. The usability of the IFU is part of the usability engineering file.

**8. Feed post-market data back into both files.** When a customer complaint or a post-market signal reveals a new use pattern or use error, both the risk management file and the usability engineering file must be updated. A PMS loop that only touches one of them creates a silent divergence.

## Reality Check

1. Do your risk management file and your usability engineering file share a common hazard vocabulary, or have the two files drifted?
2. Is your use specification decomposed into concrete procedures (unboxing, setup, routine use, cleaning, edge cases), or does it still say "the user uses the device"?
3. For every use-related risk in your file, can you show that the higher tiers of the control hierarchy were considered before settling on information for safety?
4. Have you ever accepted "we will train the user" or "the IFU warns against this" as the sole control for a foreseeable use error?
5. If your device is connected to an app, does the app's usability appear in the usability engineering file under EN 62366-1:2015+A1:2020?
6. During summative, did you test the IFU by handing it to users with no coaching, or did the team guide participants through the steps?
7. When post-market data arrives, does it update both the risk file and the usability file, or only one?
8. If an auditor asked you to walk from a single use scenario to a single residual risk, crossing both files, could you do it in under two minutes?

## Frequently Asked Questions

**Is usability engineering required for every device, or only Class II and above?**
Usability considerations apply to every device under MDR Annex I §5. The depth of the usability engineering file scales with risk class, but no device is exempt from the obligation to minimise use-related risks.

**Can we run risk management and usability engineering on different timelines?**
In practice, the usability engineering process should start as early as the risk management process, during design planning. Running them sequentially creates rework. Running them in parallel, with a shared vocabulary, is cheaper.

**Does EN 62366-1:2015+A1:2020 replace EN ISO 14971:2019+A11:2021 for use-related risks?**
No. EN 62366-1 describes how to identify and evaluate use-related hazards. EN ISO 14971 remains the governing process for overall risk management. The usability file feeds the risk file.

**What counts as a representative user for summative evaluation?**
Users matching the intended user profile in the use specification: medical background, experience level, age range, and relevant impairments. Engineers, sales staff, friendly customers, and key opinion leaders are not representative users. Tibor flagged this as a common audit finding in the follow-up interview.

**Can a training programme count as a risk control?**
Only as information for safety, the lowest tier of the control hierarchy, and only as a supplement to higher-tier controls where feasible. Training as the sole control for a foreseeable use error is a common non-conformity.

**What about software-only devices? Is usability still a separate file?**
Yes. Software-only devices fall under EN 62366-1:2015+A1:2020 in the same way as hardware. The use specification, the user interface specification, the hazard-related use scenarios, and the summative evaluation all apply.

## Related reading

- [Risk management for medical devices: startup primer](/blog/risk-management-medical-devices-startup-primer) for the baseline process the usability file feeds into.
- [MDR risk management process under ISO 14971](/blog/mdr-risk-management-process-iso-14971) for the full EN ISO 14971 workflow.
- [IEC 60601-1-6 usability cross-reference](/blog/iec-60601-1-6-usability-cross-reference) for the electrical-device usability layer.
- [The ISO 14971 Annex Z trap](/blog/iso-14971-annex-z-trap) for the MDR ratchet that also governs use-related risks.
- [PMS feedback into the risk management file](/blog/pms-feedback-risk-management) for closing the loop from real-world use errors back to the files.

## Sources

1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I Chapter I (General Safety and Performance Requirements), §5 (ergonomics and intended users), §22 (lay users).
2. EN ISO 14971:2019+A11:2021, Medical devices. Application of risk management to medical devices.
3. EN 62366-1:2015+A1:2020, Medical devices. Part 1: Application of usability engineering to medical devices.
4. EN ISO 13485:2016+A11:2021, Medical devices. Quality management systems. Requirements for regulatory purposes.

---

*This post is part of the [Risk Management Under MDR](https://zechmeister-solutions.com/en/blog/category/risk-management) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*