---
title: MDR Usability and Risk Management: IEC 62366 and ISO 14971
description: How EN 62366-1 and EN ISO 14971 operate as a coupled system under MDR, with the URRA bridging usability and risk management.
authors: Tibor Zechmeister, Felix Lenhard
category: Usability Under MDR
primary_keyword: usability risk management IEC 62366 ISO 14971
canonical_url: https://zechmeister-solutions.com/en/blog/mdr-usability-risk-management-iec-62366-iso-14971
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# MDR Usability and Risk Management: IEC 62366 and ISO 14971

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

> **Under MDR, EN 62366-1:2015+A1:2020 and EN ISO 14971:2019+A11:2021 are not two separate files. They are a coupled system. The use specification feeds hazard identification. The use-related risk analysis (URRA) bridges both processes. Summative evaluation findings feed back into the risk management file. Treating them as parallel paperwork tracks is one of the most common audit findings Tibor sees at startups.**

**By Tibor Zechmeister and Felix Lenhard.**

## TL;DR
- EN 62366-1:2015+A1:2020 (usability engineering) and EN ISO 14971:2019+A11:2021 (risk management) are designed to interoperate. MDR requires both and assumes their outputs will be reconciled.
- The bridge is the use-related risk analysis (URRA). It takes the use specification and user interface specification from EN 62366-1 and pushes hazard-related use scenarios into the EN ISO 14971 hazard list.
- Use errors are risk management inputs, not training problems. Tibor's Q7 lesson: when a team labels a use error "we will fix it in training", the auditor treats it as an unmitigated hazard.
- Summative evaluation is not only a usability deliverable. Its findings are post-hoc inputs to the risk file. Probabilities and severities may need to be updated based on what real users actually do.
- MDR Annex I §5 and §22 require use-related risks to be reduced as far as possible, applying the same ratchet that governs mechanical, biological, and electrical risks.

## Why the two standards must run as one system

Tibor has seen the same failure shape at startup after startup. One team owns the risk management file. A different team, sometimes a contractor, owns the usability engineering file. The files are written, reviewed, and submitted in parallel. Neither team reads the other file. The notified body reviewer reads both and finds contradictions within an hour.

One handheld-device story illustrates the stakes. A left-handed-dominated engineering team optimised the display for a left-hand hold. The risk file listed no use-related hazard for handedness. The summative evaluation with right-handed users revealed the display looked upside down. The hazard had always existed. The two files had never been cross-checked, so it never surfaced until real users in a real scenario tripped it. The fix was a software orientation flip, but only after summative had run. Had the risk file been populated from a properly-decomposed use specification, the handedness hazard would have been on the list from day one.

Felix works with founders who keep asking the same question: "Which file does this go in?" The question is the problem. In a properly coupled system, the answer is "both, and the two entries trace to each other".

## What MDR actually says

The MDR requires usability risks to be controlled and uses the same "as far as possible" standard it applies to any other risk class.

**MDR Annex I, Chapter I (General Safety and Performance Requirements).** Manufacturers must reduce risks as far as possible, including risks related to the use of the device. The ratchet does not exempt use errors. A use error that could have been engineered out with a better user interface, but was left in with a warning label, is not compliant.

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

**MDR Annex I §22.** Devices intended for use by lay persons shall perform appropriately taking into account the skills and means available to those lay users and the reasonably foreseeable variation in technique and environment. Lay-user devices face a higher bar.

**EN 62366-1:2015+A1:2020.** The harmonised usability engineering standard. Process steps: prepare use specification, identify user interface characteristics related to safety, identify known and foreseeable hazards and hazardous situations related to the user interface, identify and describe hazard-related use scenarios, select hazard-related use scenarios for summative evaluation, establish and carry out formative evaluation, establish and carry out summative evaluation, document the usability engineering file.

**EN ISO 14971:2019+A11:2021.** The harmonised risk management standard. Process steps: risk management planning, risk analysis (identification of hazards and hazardous situations, estimation of risk), risk evaluation, risk control, evaluation of overall residual risk, risk management review, production and post-production activities.

The coupling point is explicit in both standards. EN 62366-1 requires that hazard-related use scenarios flow into the risk management process. EN ISO 14971 requires that the hazard list cover use-related hazards. Neither standard is complete on its own.

A practical note on the MDR ratchet. EN ISO 14971 alone uses the "as low as reasonably practicable" (ALARP) concept in its Section 6 handling of initially-acceptable risk. MDR Annex I §1-9 is stricter than ALARP. MDR requires "as far as possible" regardless of initial acceptability. The Annex Z of the harmonised version (the +A11:2021 amendment) exists precisely to flag this gap. Teams that copy ISO 14971 verbatim and miss the Annex Z guidance leave a compliance hole Tibor flags on almost every first surveillance audit.

## A worked example: the tongue-and-mouth wheelchair control

A startup develops a mouthpiece-controlled wheelchair for quadriplegic patients. The team runs its EN 62366-1 process by the book. They write a use specification covering wheelchair operation in daily-living scenarios. They run formative evaluation indoors. They prepare for summative.

An auditor looks at the use specification and asks a single question: "Does the patient ever go outside?" The team answers yes. The auditor asks whether the use specification and the hazard analysis considered outdoor conditions. They had not.

The mouthpiece colour had been chosen during design as a user-interface specification decision. The chosen colour turned out to attract bees. A patient using the chair outdoors could be stung directly on the mouthpiece, potentially triggering an allergic reaction in a user who cannot physically remove the mouthpiece without assistance.

Trace the coupling:

1. **Use specification (EN 62366-1).** Use scenarios must include outdoor operation. Decomposing "uses the wheelchair" into cleaning, transport, installation, indoor operation, outdoor operation, and edge cases makes the outdoor scenario visible.
2. **User interface characteristics related to safety (EN 62366-1).** Mouthpiece colour is a user-interface characteristic with safety relevance.
3. **Hazard-related use scenario.** "Patient operates wheelchair outdoors, insect is attracted to the mouthpiece, patient cannot remove mouthpiece in time."
4. **Hazard list entry (EN ISO 14971).** Biological hazard (sting, potential allergic reaction). This entry is a use-related hazard that originated in the usability file.
5. **Risk estimation.** Probability estimated using outdoor-use prevalence and bee-attraction colour data. Severity estimated including anaphylaxis possibility.
6. **Risk control.** Inherent safety by design: change the colour to one that does not attract insects. Safety by functionality: quick-release mechanism. Information for safety: outdoor usage guidance in the IFU. The hierarchy matters. Tibor's Q8 point: startups reach for information-for-safety first because it is cheapest. Auditors reject this when design changes were available.
7. **Verification and summative evaluation.** The redesigned mouthpiece is tested in outdoor conditions during summative. The summative report entries update the risk file.

The chain has one feature worth noticing. Every step traces to a specific document, but the documents are from two standards. The file-to-file linking is what makes the system work.

## The Subtract to Ship playbook

Felix's advice to founders on the usability-plus-risk coupling is to stop treating them as two projects. Three operational moves make the coupling work without doubling the overhead.

**1. Write one combined plan, not two.** A usability engineering plan and a risk management plan can share one document with two sections and a single reviewer sign-off. The plan names the coupling points explicitly. The use specification feeds hazard identification. Formative findings update the draft risk file. Summative findings update the final risk file. Writing this down as a plan turns the coupling from "we meant to" into an audit-traceable process.

**2. Use the URRA as the working document.** The use-related risk analysis is a table that lists each hazard-related use scenario, the associated hazard, the estimated risk, the chosen control, the verification evidence, and the residual risk. It lives on the usability side but references every risk file entry it touches. Tibor recommends starting the URRA at the earliest use specification draft, not after summative. By summative, the URRA should already be mostly complete and summative should be confirming, not discovering.

**3. Fold summative results into the risk management review.** Summative evaluation is not only a deliverable for EN 62366-1. Its findings are inputs to the overall residual risk evaluation under EN ISO 14971. If summative uncovers a new hazard-related use scenario or changes the probability estimate of a known one, the risk file must be updated before the risk management review signs the overall residual risk acceptable. Tibor has seen startups submit a summative report that directly contradicted a risk file claim. The auditor catches this every time.

**Subtract move.** Founders often assume they need separate teams for risk and usability. They do not. A small cross-functional team writing both files in parallel, with one person responsible for the URRA as the bridge document, handles the coupling cleaner than two specialist teams handing off documents. The subtraction is the handoff, not the work.

## Reality Check

1. Does the startup have one combined usability-plus-risk plan, or two disconnected plans?
2. Is the use specification decomposed into real-world procedures (cleaning, transport, installation, normal operation, edge cases, environmental extremes), or does it say "user uses the device"?
3. Does the risk file contain hazard-related use scenarios that trace back to specific entries in the use specification?
4. When formative evaluation uncovered a problem, was the risk file updated? Is that update traceable?
5. Is there a URRA (use-related risk analysis) document that lives between the usability and risk files, or is that bridge missing?
6. Does the team treat "we will fix this in training" as an acceptable risk control? Under MDR Annex I §5 and the risk control hierarchy, information for safety is the last resort, not the first.
7. Has the team checked whether the EN ISO 14971 ALARP assumption is silently built into the risk file? Does Annex Z guidance and the MDR "as far as possible" standard override it?

## Frequently Asked Questions

**Do we need a separate URRA document, or can it live inside the risk file?**
Either structure works as long as the bridge is explicit. A separate URRA is clearer for notified body reviewers because it lets them audit the usability-to-risk handoff in one place. An embedded URRA inside the risk file works if the entries are tagged with their use specification origin.

**How early should summative evaluation influence the risk file?**
As soon as the summative protocol is written. The protocol itself often exposes missing hazard-related use scenarios. The findings update the risk file before the risk management review, not after submission.

**What is the difference between a use error and a use-related risk?**
A use error is an action or omission by the user that produces an unintended result. A use-related risk is the combination of that error with a hazardous situation and the potential harm. Risk management cares about the chain from error to harm, not the error itself.

**Can we argue that a use error is not our problem because the user was untrained?**
No. MDR Annex I §5 requires the design to take into account the technical knowledge, experience, education, training, and use environment of intended users. Blaming the user does not transfer the obligation.

**Is EN 62366-1:2015+A1:2020 the current harmonised edition?**
Yes. The +A1:2020 amendment is the current harmonised edition under MDR as of publication.

**Does this apply to software-only devices and mobile apps?**
Yes. Software user interfaces are covered by EN 62366-1 exactly as physical user interfaces are. App usability and hardware usability fold into the same file when the product is a connected device.

## Related reading

- [The connection between risk management and usability engineering under MDR](/blog/risk-management-usability-engineering-link). The short form of the same coupling argument.
- [MDR usability requirements and IEC 62366-1 conformity](/blog/mdr-usability-iec-62366-1-conformity). How EN 62366-1 demonstrates MDR conformity.
- [IEC 60601-1-6 usability cross-reference](/blog/iec-60601-1-6-usability-cross-reference). How the electrical-equipment collateral points at EN 62366-1.
- [The ISO 14971 Annex Z trap](/blog/iso-14971-annex-z-trap). Why the ALARP assumption in ISO 14971 is not MDR-compliant without Annex Z.
- [How PMS feedback feeds the risk management file](/blog/pms-feedback-risk-management). Closing the loop after launch.

## Sources

1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I, Chapter I, General Safety and Performance Requirements, §1-9, §5, §22.
2. EN 62366-1:2015+A1:2020. Medical devices, Part 1: Application of usability engineering to medical devices.
3. EN ISO 14971:2019+A11:2021. Medical devices, Application of risk management to medical devices.

---

*This post is part of the [Usability Under MDR](https://zechmeister-solutions.com/en/blog/category/usability) 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).*