--- title: Training Requirements as Risk Control under MDR description: When training is a legitimate MDR risk control and when it is a cop-out: the hierarchy from EN ISO 14971 and EN 62366-1 explained for startups. authors: Tibor Zechmeister, Felix Lenhard category: Usability Under MDR primary_keyword: training risk control usability MDR canonical_url: https://zechmeister-solutions.com/en/blog/training-requirements-risk-control-usability source: zechmeister-solutions.com license: All rights reserved. Content may be cited with attribution and a link to the canonical URL. --- # Training Requirements as Risk Control under MDR *By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.* > **Training is a legitimate risk control under MDR only when it sits at the bottom of the risk control hierarchy defined in EN ISO 14971:2019+A11:2021 and applied through EN 62366-1:2015+A1:2020, which means after inherent safety by design and after protective measures have been exhausted. When a startup reaches for training first, a notified body will read it as a design flaw dressed up in paperwork.** **By Tibor Zechmeister and Felix Lenhard.** ## TL;DR - MDR Annex I §4 requires manufacturers to reduce risks as far as possible, and Annex I §5 specifically targets use-related risks and ergonomic design. - The risk control hierarchy from EN ISO 14971:2019+A11:2021 has three levels: inherent safety by design, protective measures, then information for safety including training. - Training qualifies as a credible risk control for specialist professional users with an existing competency baseline, not for lay users operating a device at home. - The most common notified body finding in this area is a startup that skipped levels one and two and routed every residual use-related hazard into the instructions for use or a training module. - A device intended for lay users under MDR Annex I §22 faces stricter requirements and training alone will almost never close the gap. - When training is used, it must be specified, delivered, verified, and monitored across the product lifecycle, not declared in a single line of the instructions for use. ## Why this matters for startups applying for CE marking Tibor has seen a predictable pattern in first-time notified body submissions. A startup identifies a use-related hazard during risk analysis. Instead of redesigning the user interface, the team writes a sentence into the instructions for use and adds a training module to the onboarding. The risk is then declared acceptable. The auditor disagrees. The hazard analysis is reopened. The device is held on the market until the design iteration is completed, verified, and a change control procedure has been run. The business cost is measured in months of lost revenue and notified body fees for the re-engagement. Felix has watched the same pattern from the founder side. The decision to train instead of redesign almost always happens under schedule pressure. The design change looks expensive today. The training line looks free. The real cost is postponed to a post-market finding, where a field safety corrective action, an urgent software change, or a full change control will eat an order of magnitude more engineering time than the design fix would have cost before freezing the interface. The reason this keeps happening is that founders read MDR Annex I in isolation. Annex I §4 requires risk reduction "as far as possible". Annex I §5 addresses use-related risks. But the sequencing, the actual hierarchy of which control type must be tried first, lives in EN ISO 14971:2019+A11:2021 and in EN 62366-1:2015+A1:2020. A founder who has not read those two standards carefully will read the Annex I clauses as permission to pick whichever control is cheapest. It is not permission. It is a mandate to work through the hierarchy in order. ## What the standards actually say EN ISO 14971:2019+A11:2021 sets out the risk control option analysis in three priorities. The first priority is **inherent safety by design**. This means eliminating the hazard altogether by changing the device, the materials, the circuit, the software logic, or the physical form. The second priority is **protective measures** in the device itself or in the manufacturing process. This is where automatic shutoffs, interlocks, alarms, physical guards, error handling in software, and redundancy all belong. The third and final priority is **information for safety**, which includes labels, warnings, the instructions for use, and, where justified, user training. Tibor's framing is blunt. Safety by information is a legitimate control, but it is rarely the most efficient one, and it is always the last resort. A startup skipping to level three when level one or level two was available is a classic finding. EN 62366-1:2015+A1:2020 sits on top of that hierarchy for use-related risks specifically. The standard requires a use specification, identification of hazard-related use scenarios, formative evaluation, summative evaluation, and residual risk acceptance. When the standard talks about reducing use-related risk, it means through user interface design first. Training is treated as one mechanism within the broader toolset, not as the default. EN 62366-1 also draws a distinction that matters for startups. A device intended for a specialist professional user, for example a device used only by interventional cardiologists with formal accreditation, can legitimately rely on existing professional training to close certain residual gaps. A device intended for a lay user at home, under MDR Annex I §22, cannot. Annex I §22 explicitly increases the bar for devices intended for lay users, precisely because the baseline competency cannot be assumed. Training as a compensating control collapses under Annex I §22 in most scenarios. ## A worked example: the lay-user injector Consider a hypothetical startup building a disposable drug-delivery injector intended for patients with a chronic condition. The intended user is a lay user, untrained in clinical procedure, who self-administers at home. The device is classified under MDR and EN 62366-1 applies directly, with the stricter Annex I §22 requirements also engaged. During the first risk analysis the team identifies a hazard: the user could accidentally inject at the wrong site because the two ends of the injector look similar. The team drafts a control: a warning on the device label and a training video shown once during the first-use onboarding. A notified body reviewing this file will ask three questions. First, why was the similar geometry not eliminated by design? A colour-coded, keyed, or asymmetric body would have removed the ambiguity entirely. That is level one of the hierarchy and it was skipped. Second, why was no protective mechanism considered? A mechanical interlock preventing activation at the wrong end, or a software sensor on a connected version, would be level two. That was also skipped. Third, on what evidence does the startup claim that a training video watched once will change user behaviour in a stressful moment three months later? The training control has not been validated through summative evaluation. The notified body will not reject the device outright. It will raise a nonconformity and require the startup to reopen the risk file, reconsider levels one and two, document why each level was inadequate or not feasible, and only then accept the training as a residual control. If the redesign would have been feasible, the training cannot stand. The startup has now burned several months on a loop that could have been avoided by applying the hierarchy in order from the beginning. Tibor has seen variants of this story across injectors, infusion devices, sleep therapy devices, and home-use diagnostic readers. The pattern is consistent: training is a comfortable answer on a Monday morning during sprint planning. It is not a comfortable answer in front of an auditor. ## The Subtract to Ship playbook The Subtract to Ship approach to training as risk control is a discipline, not a philosophy. It consists of six steps that a startup can run during design iterations. **Step one: write the hierarchy into the risk management plan.** The risk management plan required under EN ISO 14971:2019+A11:2021 should explicitly state that every use-related risk must be evaluated at level one first, then level two, then level three. The plan is the contract between the startup and the notified body. **Step two: maintain a "design change considered and rejected" log.** When level one is not feasible, document why in the risk file. When level two is not feasible, document why. This log is the evidence trail that the hierarchy was followed. Without it, an auditor will assume it was not. **Step three: define who the user actually is.** This is the use specification step from EN 62366-1:2015+A1:2020. A device for certified surgical teams in a hospital has a different training baseline than a device for a 70-year-old patient at home. The training argument that works for the first collapses for the second. Be explicit. **Step four: when training is used, specify it as a controlled artefact.** The training content, duration, learning objectives, verification method, and refresh cadence all belong in a controlled document under the quality management system referenced by EN ISO 13485:2016+A11:2021. A sentence in the instructions for use is not a training programme. **Step five: verify training effectiveness in summative evaluation.** If the startup claims that training reduces a residual risk, the claim must be tested. Recruit representative users, run the device through hazard-related scenarios after the training has been delivered, and measure whether the hazard still occurs. If it does, the training did not work and the risk is not acceptable. **Step six: monitor training effectiveness post-market.** Under MDR Articles 83 to 86, the post-market surveillance system must feed back into the risk file. If customer complaints and incident reports show the same use error the training was supposed to prevent, the control has failed and the hierarchy must be reopened from the top. Felix's coaching experience is that step two and step five are the ones startups skip. Writing the design change log feels like bureaucracy. Testing training effectiveness feels like extra work. Both are, in fact, the two steps that prove to a notified body that the hierarchy was genuinely applied rather than rhetorically gestured at. ## Reality Check 1. Has the risk management plan been updated to require explicit application of the three-level hierarchy to every use-related risk? 2. For every use-related hazard currently controlled by training or information in the risk file, is there a documented rejection rationale for level one and level two? 3. Is the intended user a specialist professional with an existing competency baseline or a lay user under MDR Annex I §22? 4. If training is claimed as a control, is the training content held as a controlled document under the quality management system? 5. Has the effectiveness of any training-based control been verified during summative evaluation with recruited users? 6. Does the post-market surveillance procedure include a trigger that reopens the risk file when recurring use errors suggest a training control has failed? 7. For a lay-user device, has the team honestly asked whether any design change at level one could eliminate the residual hazard entirely? ## Frequently Asked Questions **Is training ever an acceptable primary risk control under MDR?** Only when inherent safety by design and protective measures have both been analysed and documented as not feasible, and when the intended user has the professional baseline to absorb the training reliably. For lay users under MDR Annex I §22, this combination almost never holds. **Does the notified body expect a written rationale for why level one was rejected?** Yes. An auditor cannot read minds. If the risk file does not contain a documented design change analysis, the auditor will treat the absence as evidence that the hierarchy was not applied. **What is the difference between training and information for safety?** Information for safety is passive: the user reads a label, a warning, or an instruction. Training is active: the user completes a structured learning activity and, ideally, is verified as competent. Both sit at the lowest priority in the EN ISO 14971:2019+A11:2021 hierarchy. **Can the training be delivered by a distributor or by the importer?** The manufacturer remains responsible. Delegation of delivery is allowed, but the specification, verification, and lifecycle monitoring of the training are all obligations retained by the legal manufacturer. **What happens if the post-market data shows training is not working?** The control has failed. The risk file must be reopened. The hierarchy must be re-evaluated from level one. In practice this usually triggers a design change, a change control procedure with the notified body, and an update to the technical documentation. **Is an instructional video enough?** A video can be one component of a training programme, but on its own it rarely satisfies the specification, verification, and monitoring obligations. Videos without verification and refreshers are closer to information for safety than to training. ## Related reading - [Usability Engineering for Medical Devices: A Startup Introduction](/blog/usability-engineering-medical-devices-startup) gives the full EN 62366-1:2015+A1:2020 process this post sits inside. - [MDR Risk Control: The Three-Step Hierarchy from ISO 14971](/blog/mdr-risk-control-three-step-iso-14971) walks through the hierarchy in depth with further examples. - [Risk Management and Usability Engineering: The Link](/blog/risk-management-usability-engineering-link) explains how the two standards plug into each other in a startup quality management system. ## Sources 1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I §2, §4, §5, §22. 2. EN ISO 14971:2019+A11:2021, Medical devices, Application of risk management to medical devices. Clause on risk control option analysis. 3. EN 62366-1:2015+A1:2020, Medical devices, Part 1, Application of usability engineering 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).*