--- title: MDR Usability: How IEC 62366-1 Demonstrates Conformity description: MDR usability IEC 62366-1 conformity: how EN 62366-1:2015+A1:2020 provides presumption of conformity with MDR Annex I §5 and §22. authors: Tibor Zechmeister, Felix Lenhard category: Usability Under MDR primary_keyword: MDR usability IEC 62366-1 conformity canonical_url: https://zechmeister-solutions.com/en/blog/mdr-usability-iec-62366-1-conformity source: zechmeister-solutions.com license: All rights reserved. Content may be cited with attribution and a link to the canonical URL. --- # MDR Usability: How IEC 62366-1 Demonstrates Conformity *By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.* > **EN 62366-1:2015+A1:2020 is the harmonised standard the European Commission lists for the usability engineering of medical devices. When a manufacturer applies it correctly, the resulting usability engineering file gives a presumption of conformity with the ergonomic and lay-user obligations in MDR Annex I §5 and §22. The standard does not replace the regulation, but it is the most direct evidence route a startup can use.** **By Tibor Zechmeister and Felix Lenhard.** ## TL;DR - MDR Article 8 establishes that applying a harmonised standard provides a presumption of conformity with the relevant general safety and performance requirements it covers. - EN 62366-1:2015+A1:2020 is the harmonised standard for usability engineering and is the route notified bodies expect for Annex I §5 and §22. - Presumption of conformity is not automatic. It depends on applying the standard correctly, not on quoting its title in the technical documentation. - A group review of a prototype is not a summative evaluation and will not support the presumption of conformity on its own. - The usability engineering file produced under EN 62366-1 is a required deliverable, and notified bodies review it alongside the risk management file and the clinical evaluation. ## What presumption of conformity actually means Tibor has spent years on both sides of the audit table, and the single concept he sees most misunderstood by startup founders is the phrase *presumption of conformity*. It sounds like a guarantee. It is not. It is a legal mechanism that shifts the burden of proof. Under MDR Article 8, when a manufacturer applies a harmonised standard whose reference has been published in the *Official Journal of the European Union*, the parts of the device covered by that standard are presumed to conform with the corresponding general safety and performance requirements in Annex I. In practice this means that if the standard is applied correctly and the evidence is on file, the notified body and any competent authority start from the assumption that the requirement is met. They can still ask questions. They can still find fault with the execution. But they are not expected to relitigate the underlying requirement from first principles. For usability engineering, the harmonised standard is EN 62366-1:2015+A1:2020. That is the exact name a startup should use in its technical documentation and in any reference to the standard in the risk management file, the clinical evaluation, and the labelling justifications. It is not EN IEC 62366-1. It is not ISO 62366-1. The precise reference matters because notified bodies check the reference against the harmonised standards list published by the European Commission. Felix's blunt version of the same point for Subtract to Ship founders is that presumption of conformity is a door that opens easily if the manufacturer walks up to it the right way, and stays firmly shut if the manufacturer tries to force it. The standard is the key shape. Applying it sloppily does not produce a sloppy key. It produces no key at all. ## How EN 62366-1 maps onto Annex I §5 and §22 MDR Annex I §5 is the ergonomic general safety and performance requirement. It requires that devices, and any associated environment of intended use, be designed and manufactured in such a way as to reduce as far as possible the risks linked to the ergonomic features of the device and the environment in which the device is intended to be used. It also addresses consideration of the technical knowledge, experience, education, training, use environment, and medical and physical conditions of intended users. MDR Annex I §22 applies specifically to devices intended for use by lay persons. It requires that such devices be designed and manufactured in such a way that they perform appropriately for their intended purpose, taking into account the skills and means available to lay users and the influence resulting from variation that can be reasonably anticipated in the user's technique and environment. EN 62366-1:2015+A1:2020 covers both of these requirements by prescribing a structured process that produces exactly the evidence a notified body needs. The standard requires a use specification, hazard-related use scenario analysis, formative evaluation during development, and summative evaluation before release. The outputs of each step become entries in the usability engineering file. That file is what the notified body reviews. The mapping, in Tibor's audit experience, runs as follows. The use specification and hazard-related use scenario analysis address the Annex I §5 requirement that the manufacturer has considered the characteristics of the intended user and use environment. The formative evaluations show that usability was designed in, not bolted on. The summative evaluation demonstrates that the residual use-related risk is acceptable given the intended user group. For devices used by lay persons, the summative evaluation recruits lay users specifically and tests in an environment that resembles the home or community setting, which is how the manufacturer builds the Annex I §22 evidence. ## Where the presumption falls apart The presumption of conformity is not a magic phrase. Tibor has seen it lost in three common ways. The first is the group-review trap. The startup runs an informal review of the prototype, concludes everything looks fine, and calls it summative. The usability engineering file contains a memo. There are no recruited users, no recorded observations, no tie-back to hazard-related use scenarios. The file fails to satisfy the standard and therefore no longer supports presumption of conformity. The notified body asks for a real summative. The second is the wrong-users trap. The startup runs a summative, but the participants are engineers, sales staff, or key opinion leaders. The file looks complete at first glance. Under audit scrutiny the recruited users are not representative of the intended user group. The evidence does not support the conclusion that residual use-related risk is acceptable for real users, and the presumption is lost. The third is the orphaned-file trap. The usability engineering file exists, but it does not connect to the risk management file under EN ISO 14971:2019+A11:2021. Hazard-related use scenarios were identified, but never flowed through to the risk analysis. The notified body asks one question that breaks the whole chain: where in the risk file does this use-related hazard appear? Tibor has watched that single question unwind weeks of work. ## A worked example: a Class IIa infusion accessory Consider a startup building a Class IIa accessory that attaches to existing infusion pumps and provides a simplified interface for home-care nurses. The regulatory lead has listed EN 62366-1:2015+A1:2020 in the technical documentation and has checked the harmonised standards list to confirm the reference is current. The startup writes a use specification that decomposes the user experience into unboxing, installation on a pump, calibration, starting an infusion, alarm response, cleaning, and storage. Each step identifies the intended user (home-care nurse), the use environment (patient's home), and the user interface elements involved. Hazard-related use scenarios are identified for each step: misattachment that goes unnoticed, calibration that completes on an unready state, an alarm that is silenced without triage, and cleaning that damages a sensor. Formative evaluations run with four home-care nurses during development. Two of them struggle with the alarm acknowledgement flow. The interface is redesigned. A second formative confirms the improvement. Summative evaluation then runs with 15 recruited home-care nurses in a simulated patient-home environment. Tasks are scored against the hazard-related use scenarios. Observations are recorded. The outcomes are documented in the usability engineering file. Each residual risk is traced to the risk management file under EN ISO 14971:2019+A11:2021 and reviewed in the risk-benefit analysis. When the notified body audits the technical documentation, the presumption of conformity with Annex I §5 holds because the standard was applied correctly and the file is traceable end to end. The notified body raises minor observations but does not question whether the manufacturer understood the ergonomic requirement. ## The Subtract to Ship playbook for claiming conformity correctly Step one. Cite the exact standard reference in the technical documentation: EN 62366-1:2015+A1:2020. Check the harmonised standards list published in the Official Journal before every notified body submission in case the reference has been updated. Step two. Build the usability engineering file as the standard defines it, not as a freeform narrative. The file has expected contents: use specification, user interface specification, user interface evaluation plan, formative and summative reports, and conclusions. Notified bodies know what they expect to see. Step three. Link the usability engineering file to the risk management file under EN ISO 14971:2019+A11:2021. Every hazard-related use scenario should appear in the risk analysis. Every use-related residual risk should appear in the risk-benefit analysis. Step four. Do not fabricate the summative evaluation. Recruit representative users. Simulate the real environment where a real environment is not feasible. Record observations. Tie outcomes to hazard-related use scenarios. This is the part startups are tempted to shortcut, and it is the part notified bodies scrutinise most carefully. Step five. If the device has a software component, include the software user interface in the usability engineering file. Folding the app interface into the hardware file is cheaper and more defensible than maintaining two separate usability positions. ## Reality Check 1. Is the exact reference EN 62366-1:2015+A1:2020 cited in the technical documentation and confirmed against the current harmonised standards list? 2. Does the usability engineering file contain all the sections the standard expects, or is it a single narrative document? 3. Are all hazard-related use scenarios traceable into the risk management file under EN ISO 14971:2019+A11:2021? 4. Can the notified body see, from the summative evaluation report alone, who the users were, where the testing happened, and what was recorded? 5. For lay-user devices, were the summative participants actually lay users or were they clinicians acting as proxies? 6. Is the software user interface, if present, covered inside the same file as the hardware, or is it quietly excluded? 7. Has the usability engineering file been reviewed against Annex I §5 and §22 specifically, rather than only against the standard's own structure? 8. If a notified body asked "how does this file support presumption of conformity with Annex I §5?", could the regulatory lead answer in one sentence? ## Frequently Asked Questions **Is EN 62366-1:2015+A1:2020 mandatory under MDR?** No standard is mandatory in a strict legal sense. MDR sets the requirements in Annex I. Applying EN 62366-1:2015+A1:2020 is the route that gives presumption of conformity for the usability obligations. A manufacturer could in principle meet Annex I §5 and §22 through another demonstrable route, but in practice notified bodies expect the standard. **What is the difference between EN 62366-1 and IEC 62366-1?** The IEC version is the international standard published by the International Electrotechnical Commission. The EN version is the European adoption that is then harmonised under MDR. For European market access, the correct reference is the EN version with the full date suffix: EN 62366-1:2015+A1:2020. **Does citing the standard in technical documentation guarantee conformity?** No. Citing the standard is necessary but not sufficient. The standard has to be applied correctly and the resulting usability engineering file has to be complete, traceable, and consistent with the risk management file. **Can a startup skip formative evaluation if the summative is planned?** In principle the standard permits a single evaluation if well justified, but in Tibor's audit experience skipping formative evaluations is a false economy. Formative testing catches problems while they are cheap to fix. Discovering them during summative means redesign and retest. **How does the notified body check the presumption of conformity?** It reviews the usability engineering file, checks whether the standard was applied correctly, and inspects the traceability into the risk management file and the clinical evaluation. It does not simply accept the claim because the standard is cited. **Does the standard cover connected apps?** Yes. The standard applies to the user interface of the medical device regardless of whether the interface is physical or software. An app that controls or configures a medical device is part of the user interface and must be inside the usability engineering file. ## Related reading - [What Is Usability Engineering for Medical Devices? A Startup Introduction](/blog/usability-engineering-medical-devices-startup). Foundational primer on the EN 62366-1 process. - [MDR Annex I Usability Requirements: What the Regulation Demands](/blog/mdr-annex-i-usability-requirements). The regulatory text that the standard gives presumption of conformity with. - [MDR Annex I GSPR Primer](/blog/mdr-annex-i-gspr). How usability sits inside the wider general safety and performance requirements. - [IEC 60601-1-6 Usability Cross-Reference](/blog/iec-60601-1-6-usability-cross-reference). How the collateral standard for electrical equipment links into the EN 62366-1 process. ## Sources 1. Regulation (EU) 2017/745 on medical devices, consolidated text. Article 8 (harmonised standards) and Annex I §5 and §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).*