What Is IEC 62366? A Guide to Medical Device Usability Engineering

A nurse on a busy ward taps through a dose confirmation on an infusion pump and moves to the next patient without breaking stride. That kind of confident, almost invisible interaction is what a good usability engineering program produces, and what keeps reviewers from flagging use errors the team never tested for.

IEC 62366 turns that outcome into a documented, risk-based process with evidence reviewers can actually follow. This guide covers the nine-step usability engineering process and how the standard ties into ISO 14971, ISO 13485, FDA 21 CFR Part 820 (QMSR), and EU MDR.

What Is IEC 62366?

IEC 62366 is the international standard for applying usability engineering to medical devices. It defines a risk-based process for building a user interface around the clinical tasks people actually perform, then generating evidence that the residual use-related risk is acceptable.

The scope is normal use, which covers correct use plus the use errors a reasonable intended user could make in the intended environment. Willful misuse and sabotage sit outside the process. The IEC publishes the standard, and ANSI/AAMI distribute the harmonized US version as ANSI/AAMI/IEC 62366-1:2015+AMD1:2020, which the FDA recognizes as a consensus standard for premarket submissions.

IEC 62366-1 vs. IEC 62366-2

IEC 62366-1 is the binding specification. IEC/TR 62366-2 is a companion Technical Report with worked examples and practical methods. Teams conform to Part 1, and they read Part 2 to decide how to execute it.

Citing Part 2 in a submission does not establish conformity. That confusion is common in first-time submissions and often surfaces during notified body review when the Declaration of Conformity points at the wrong document.

Key Changes in IEC 62366-1 Amendment 1 (2020)

Amendment 1 is a targeted update to IEC 62366-1:2015. It did not redesign the process, but teams still running on the 2015 base text carry real risk in their Usability Engineering File (UEF) and use-related risk analysis (URRA). Four updates drive the rework needed before the next submission:

• Updated risk reference: The normative reference moved to ISO 14971:2019. Risk files still citing the 2007 edition read as out of date during review and often force a revision cycle.
• Training as a risk control: The amendment adds training to the accepted risk controls, alongside inherent safe design and information for safety like labeling, instructions for use, and alarms. Training-dependent controls now need documented rationale and evidence.
• New summative standard of proof: Fixed pass/fail acceptance criteria are gone. The outcome hinges on objective evidence that residual use-related risk is acceptable, so task completion metrics become inputs to that judgment instead of a gate.
• Cleaner terminology: “Action error” became “physical mismatch” to describe the gap between task demands and user physical capabilities. Hazards are no longer limited to physical hazards, and environment of use now accounts for social factors.

Any UEF, URRA, or human factors protocol still referencing ISO 14971:2007 or “action error” needs a pass before the next submission. The scenario selection and summative evidence sections deserve the most careful read, since reviewers tend to probe those hardest.

The IEC 62366-1 Usability Engineering Process Step by Step

Part 1 describes an iterative, risk-driven process that produces auditable evidence at every step. Teams work from intended use down to hazard-related scenarios and back up to verification results through nine stages:

1. Use specification: A plain-language record of intended users, intended use, use environments, and user interface (UI) scope. Every downstream activity traces back to it, so ambiguity here propagates.
2. Safety-related UI characteristics: Identify UI elements tied to safe operation, such as alarm behaviors, confirmation screens, and lockout states. Downstream hazard analysis focuses on these.
3. Known and foreseeable hazards: Capture the use errors and hazardous situations you can anticipate from the use specification, prior devices, complaints, and literature.
4. Hazard-related use scenarios: For each hazard, document the task list, the task sequence, and the severity of harm. This is where URRA takes shape.
5. Scenario selection for summative evaluation: Pick the scenarios that represent the most clinically significant use errors. Write the rationale for what you included and what you excluded, because reviewers read the excluded list.
6. UI specification: Turn the hazard analysis findings into testable UI design requirements that trace back to the use errors they address.
7. UI evaluation plan: Define the formative and summative activities, participant criteria, test conditions, and acceptance inputs before testing starts.
8. Formative evaluations: Run expert reviews, cognitive walkthroughs, and simulated-use testing through development to surface issues while there is still time to change the design.
9. Summative evaluation: Run simulated-use testing with representative intended users on a final or near-final UI to generate evidence that residual use-related risk is acceptable.

The process runs as a loop. Formative findings feed design changes, design changes feed URRA updates, and URRA updates can pull scenario selection back into play before the summative study starts.

Formative vs. Summative Evaluations

Formative evaluation is iterative design testing during development. Summative evaluation is the validation study near design freeze that produces the objective evidence of acceptable residual use-related risk. Study design mistakes in either one tend to show up as FDA deficiencies, and the two are not interchangeable.

IEC 62366-1 does not set a minimum sample size, so study design has to match the user groups and critical tasks defined in the use specification. The FDA human factors guidance expects a minimum of 15 participants per distinct user population for validation testing, which most US submissions plan against as a working baseline.

What Auditors Look for in a Usability Engineering File

The Usability Engineering File is the evidence package that documents the whole process, and it is often the first artifact auditors open. The core requirement is an auditable chain running from intended users and environments through safety-related UI characteristics, known hazards, hazard-related use scenarios, risk control measures, and summative evaluation evidence. The URRA connects usability and risk management, and breaks in that chain are where most findings land.

When a reviewer asks why a control was selected or how an error was mitigated, a well-maintained UEF puts the answer one click away instead of a three-week records hunt. Auditors typically probe four areas:

• Use specification completeness: Missing user groups (home caregivers on a device marketed for home use), outdated environment descriptions, and UI scope that does not match the current design are common findings.
• Use error to hazard linkage: Orphan use errors with no hazard connection, or hazards with no use error traced to them, signal that the URRA was assembled after the fact instead of built in.
• Scenario selection rationale: Reviewers flag excluded scenarios when the written justification does not address clinical significance, patient population, or severity of harm.
• Risk control hierarchy: If labeling shows up as the primary control without evidence that inherent safe design and protective measures were evaluated first, the response letter writes itself.

Gaps across these four elements account for most post-submission findings. Experienced teams maintain a traceability matrix that spans users, hazards, controls, and evaluation results instead of rebuilding the links by hand before each audit.

How IEC 62366 Connects to ISO 14971, ISO 13485, FDA, and EU MDR

IEC 62366-1 fits into the quality, risk, and regulatory frameworks already in place. Four connections cover what teams need to wire into their quality management system:

• ISO 14971 risk management: IEC 62366-1 is where use-related risk gets worked out and fed into the URRA, which ISO 14971 then wraps into the overall residual risk evaluation.
• ISO 13485 quality management: The usability engineering process sits inside the ISO 13485 product realization process, and the UEF follows the same document and change control rules as every other design record.
• FDA 21 CFR Part 820 and the QMSR: The Quality Management System Regulation took effect February 2, 2026 and pulled ISO 13485:2016 into Part 820 by reference, so IEC 62366-1 conformance now aligns with FDA human factors expectations through ISO 13485 clause 7.
• EU MDR and IVDR: Annex I of the EU Medical Device Regulation (2017/745) and In Vitro Diagnostic Regulation (2017/746) contains usability-related General Safety and Performance Requirements (GSPRs), and EN IEC 62366-1 is the standard most teams cite to support conformity.

Mapping these connections once in a requirements tool avoids the rework that comes from treating usability, risk, and design control records as separate streams.

Common IEC 62366 Compliance Pitfalls

FDA deficiency letters and notified body findings show the same patterns year after year. Four mistakes cause most of the post-submission rework:

• Weak traceability between tasks, hazards, and controls: When the chain from user tasks to use errors to hazards to controls to verification evidence is maintained manually, gaps form quietly and surface during review. One FDA review of a subcutaneous infusion system traced use-related issues with critical tasks back to UI design and produced a Complete Response letter.
• Under-scoped formative evaluations: Formative testing is not explicitly mandated, but few devices pass summative validation without enough of it. Adequate rounds surface alarm comprehension issues and ambiguous labels before they become summative failures.
• Summative study design flaws: Recurring deficiencies include failing to classify tasks as critical, skipping root cause analysis for observed use errors, running the study on a non-final UI, and making design changes after the study without re-evaluation.
• Outdated references to ISO 14971:2007: UEFs still citing the 2007 risk management edition or pre-amendment terminology read as out of date during review, and reviewers tend to ask follow-up questions about everything else in the file.

Catching these during formative work is far cheaper than answering them in a deficiency letter. Experienced teams treat design control and usability records as one connected evidence set, so there are no parallel tracks to reconcile at submission time.

How Jama Connect Supports IEC 62366 Compliance

Use errors that turn into hazards rarely come from a single missed detail. They come from a break somewhere in the chain between intended user, use scenario, hazard, risk control, and verification evidence. The break is usually invisible until an auditor samples it, and the problem compounds when human factors records sit in slide decks while design requirements and risk records live in separate tools.

Jama Connect® is a requirements management platform with a pre-built framework for medical device teams aligned to IEC 62366, ISO 13485, ISO 14971, and FDA design controls. User needs, hazard-related use scenarios, UI requirements, URRA entries, and verification records connect in one system. Live Traceability™ is the Jama Connect capability that keeps those links current as designs change, so a formative-driven design change flags every downstream record that needs review. When an auditor asks for the evidence behind a summative result, the trace is already assembled.

Keeping Usability Evidence Audit-Ready Through Every Revision

Amendment 1 shifted the summative standard of proof to an ongoing argument about residual use-related risk. That favors a living UEF built up during design, because reconstructing one in the weeks before submission leaves too many gaps to explain. The gap shows up most clearly when a team has to respond to a deficiency letter on a short clock.

Jama Connect supports this workflow by keeping user needs, hazard analyses, design requirements, and verification evidence in a single traceable record that stays current as designs evolve. If you want to see how that runs on your own device program, start a free 30-day trial of Jama Connect today.

Frequently Asked Questions About IEC 62366

Is IEC 62366 the same as human factors engineering?

IEC 62366-1 treats usability engineering and human factors engineering as equivalent, with “Human Factors Engineering” shown in parentheses in its scope statement. The practical distinction is that IEC 62366-1 specifies the process while documents like ANSI/AAMI HE75 provide the design methods and principles.

Is IEC 62366 compliance mandatory?

In the US, IEC 62366-1 is a voluntary consensus standard. The mandatory hook is 21 CFR Part 820 design controls under the QMSR, so manufacturers that skip IEC 62366-1 still have to demonstrate equivalent usability risk management. In the EU, EN IEC 62366-1 supports conformity against the Annex I GSPRs under MDR and IVDR.

How many participants do I need for a summative evaluation?

IEC 62366-1 does not specify a minimum sample size, so the number depends on the user groups and critical tasks for the device. FDA human factors guidance expects at least 15 participants per distinct user group for summative validation, which is the baseline most US submissions plan against.

Does IEC 62366 apply to software as a medical device?

Yes. Software as a medical device (SaMD) falls within the medical device definition under FDA and EU MDR/IVDR, so submissions can cite IEC 62366-1 as an applicable standard. For SaMD, the process focuses on how users interact with decision-support and alerting workflows rather than physical controls.

This article was authored by Tom Rish on April 30, 2026.