EN 62366-1:2015+A1:2020 is the harmonised, normative usability engineering standard. IEC 62366-2 is a technical report, not a harmonised standard. It is informational guidance that shows how to apply EN 62366-1 in practice. For MDR conformity, EN 62366-1 is the reference. IEC 62366-2 is the how-to.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • EN 62366-1:2015+A1:2020 is the harmonised standard for usability engineering under MDR. Compliance with it gives presumption of conformity to MDR Annex I usability requirements.
  • IEC 62366-2 is a technical report. It is not harmonised and does not carry presumption of conformity. It is guidance on how to apply the process in EN 62366-1.
  • The technical report adds practical depth: example methods for formative and summative evaluation, guidance on writing the use specification, discussion of user interface design techniques, and worked examples of hazard-related use scenarios.
  • Tibor treats IEC 62366-2 as a useful training resource for first-time regulatory affairs leads who understand what EN 62366-1 requires but not how to do it.
  • . The technical report has been republished; confirm the edition your team references is still current before citing it in your usability engineering file.

Why this matters

Felix works with founders who pick up EN 62366-1 for the first time and freeze. The standard describes a process (use specification, user interface specification, known and foreseeable hazards, hazard-related use scenarios, formative evaluation, summative evaluation, usability engineering file) but it does not teach the techniques. How do you recruit summative participants? How do you write a use specification that is granular enough to surface hazards? How do you score formative findings? EN 62366-1 assumes you know.

Tibor's experience is that first-time teams read the normative standard, understand the structure, and then struggle with execution. They ask former colleagues, search guidance documents, copy templates of varying quality. IEC 62366-2 was written to fill exactly this gap. It is not a shortcut around EN 62366-1. It is a practical companion that explains what EN 62366-1 expects you to already know.

The distinction matters for how it is cited. When a notified body asks "which standards did you apply for usability engineering", the answer is EN 62366-1:2015+A1:2020. When a reviewer asks "how did you develop your use specification", the answer can include "we used the methods described in IEC 62366-2". The first establishes conformity. The second explains execution.

What MDR actually says

The MDR does not name IEC 62366-2. It does not name standards directly at all. What the MDR requires is in Annex I.

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 reduced as far as possible, taking into account the technical knowledge, experience, education, training, and the use environment of intended users.

MDR Annex I §22. Devices intended for use by lay persons shall perform appropriately taking into account the skills and the means available to those lay users and the reasonably foreseeable variation in technique.

MDR Article 8. Harmonised standards give presumption of conformity to the essential requirements they cover. This is the legal mechanism. A harmonised standard is a fast path to demonstrate conformity. A non-harmonised standard or technical report is not such a fast path.

EN 62366-1:2015+A1:2020. The harmonised usability engineering standard. Normative. Presumption of conformity.

IEC 62366-2. A technical report published under the IEC 62366 series. A technical report is a deliverable type that International Electrotechnical Commission publishes when the committee wants to provide informational content that is not suitable as a normative standard. Technical reports are not harmonised under MDR. They do not carry presumption of conformity. They are advisory.

The distinction is not bureaucratic. Notified bodies treat the two documents differently during audit. EN 62366-1 evidence is expected. IEC 62366-2 evidence is optional but useful.

. The IEC 62366-2 technical report has existed in more than one edition since first publication. Before citing it in a usability engineering file, confirm with the IEC electronic catalogue that the edition your team references is still the published version. Technical reports can be withdrawn or superseded without the kind of formal harmonisation review that applies to harmonised standards.

What IEC 62366-2 adds to EN 62366-1

Tibor has used both documents on real projects. The added value of the technical report falls into five categories.

Guidance on writing the use specification. EN 62366-1 requires a use specification but does not fully explain how granular to be. Tibor's Q5 observation: startups write "the user uses the device" and stop there. The technical report demonstrates decomposition into cleaning, transport, installation, normal operation, reasonably foreseeable misuse, and environmental variations. Teams that read the technical report before writing their first use specification produce documents that survive auditor review.

Practical examples of hazard-related use scenarios. A hazard-related use scenario is a specific sequence of user actions that leads to a hazardous situation. EN 62366-1 defines the concept. The technical report provides worked examples across device categories (implants, diagnostic software, infusion pumps, imaging equipment). Examples are how first-time teams learn what "good" looks like.

Methods for formative evaluation. Formative evaluation is evaluation carried out during development to inform design. Methods include cognitive walkthroughs, heuristic evaluation, think-aloud protocols, prototype-based user testing. EN 62366-1 does not prescribe methods. The technical report describes several, explains when each is appropriate, and discusses how to document findings.

Methods for summative evaluation. Summative evaluation is the final validation of the user interface with representative users in representative conditions. The technical report addresses participant selection (Tibor's Q2 point: test with real users, not engineers or friendly customers), simulated use environments (when they are acceptable, when they are not), sample sizes, observation techniques, and reporting. This section alone answers most of the questions first-time teams ask.

Interface design techniques. The technical report includes content on general interface design principles: affordances, feedback, error prevention, consistency. These are not MDR requirements directly but they are the underlying engineering techniques that produce interfaces that pass formative and summative evaluation.

A worked example

A startup developing a handheld diagnostic device reads EN 62366-1 for the first time. The team drafts a use specification of three paragraphs: "The user opens the device, runs the test, and reads the result." They plan a "summative evaluation" with three engineers on the team.

Tibor's review finds two problems. The use specification is not decomposed. The summative plan uses the wrong users.

The team then reads IEC 62366-2. They rewrite the use specification. They identify seventeen distinct use procedures: unboxing, initial installation, battery insertion, first-time power-on, test strip loading, patient sample application, result reading under various lighting conditions, cleaning after each use, disinfection between patients, storage, transport between sites, firmware update, error recovery, disposal of consumables, replacement of wear parts, long-term storage between shifts, and handover between shifts. Each of these is a procedure with its own user actions, environmental factors, and potential for error.

The hazard-related use scenario list expands from four entries to twenty-three. Five new scenarios become visible that were invisible at three paragraphs of use specification. Two of the new scenarios have safety-relevant consequences and drive design changes before summative.

The team also rewrites the summative plan. They recruit ten representative users (primary care nurses, not engineers), test in a simulated primary care environment, use a think-aloud protocol, and video-record the sessions. Findings from summative feed back into the risk file. The usability engineering file that emerges is an order of magnitude more robust than the original plan. The technical report did not change what the team had to do. It taught them how to do it.

The Subtract to Ship playbook

Felix's practical advice on IEC 62366-2 for startup teams.

1. Buy both documents together. EN 62366-1:2015+A1:2020 is the normative reference. IEC 62366-2 is the how-to. The total cost for both is a few hundred euros. Teams that try to work from EN 62366-1 alone spend weeks learning what IEC 62366-2 teaches in a day of reading.

2. Cite EN 62366-1 for conformity, cite IEC 62366-2 for methodology. In the usability engineering file, list EN 62366-1:2015+A1:2020 as the applied standard. When explaining why a formative evaluation used a particular method, reference the IEC 62366-2 section that discusses that method. Auditors appreciate the distinction.

3. Use IEC 62366-2 as a training document for new team members. When a new regulatory affairs lead joins, give them IEC 62366-2 first. It is more readable than EN 62366-1 because it is allowed to explain, not just prescribe.

4. Do not cite the technical report as if it were normative. Writing "the device conforms to IEC 62366-2" is wrong and will cause audit findings. The technical report is informational. Conformity is to EN 62366-1.

Subtract move. The technical report shrinks the "how do we actually do this" question that paralyses first-time teams. The subtraction is the weeks of trial and error.

Reality Check

  1. Has the team read EN 62366-1:2015+A1:2020 in full, or only extracted template language from it?
  2. Has the team obtained IEC 62366-2 and used it as working guidance?
  3. In the usability engineering file, is EN 62366-1 cited as the applied standard? Is IEC 62366-2 cited only as methodological reference?
  4. Before citing IEC 62366-2, has someone confirmed the edition is current? .
  5. Does the use specification reflect the decomposition depth shown in IEC 62366-2 examples, or is it a few paragraphs of general text?
  6. Did the team select formative and summative methods with reference to IEC 62366-2 guidance, or by improvisation?
  7. If a reviewer asks "why this method", can the team answer with a documented rationale?

Frequently Asked Questions

Is IEC 62366-2 a harmonised standard under MDR? No. It is a technical report. It is informational guidance. Only EN 62366-1:2015+A1:2020 is harmonised for usability engineering under MDR.

Do we have to use IEC 62366-2? No. It is optional guidance. Tibor recommends it for first-time teams because it shortens the learning curve.

Can we substitute IEC 62366-2 for EN 62366-1? No. They serve different purposes. EN 62366-1 is the normative process. IEC 62366-2 is application guidance. Both are used together.

Which edition of IEC 62366-2 should we reference? Check the current IEC catalogue before citing. Technical reports are republished without the harmonisation cycle that applies to harmonised standards. .

Does a notified body accept IEC 62366-2 as evidence of conformity? Not directly. Conformity is to EN 62366-1. Notified bodies do accept references to IEC 62366-2 as evidence that appropriate methods were applied within the EN 62366-1 process.

Is there similar guidance for EN ISO 14971? Yes. ISO/TR 24971 plays a similar role for risk management: informational guidance on how to apply the normative standard.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Article 8, Annex I §5, §22.
  2. EN 62366-1:2015+A1:2020. Medical devices, Part 1: Application of usability engineering to medical devices.
  3. IEC 62366-2. Medical devices, Part 2: Guidance on the application of usability engineering to medical devices. .