IEC 62366Medical devices — Application of usability engineering

IEC 62366-1:2015 + AMD1:2020 is the international standard that defines the usability engineering process for medical devices. It specifies a structured, documented sequence of activities — preparing a use specification, identifying user-interface characteristics related to safety, identifying hazardous situations related to use, identifying primary operating functions, performing user-interface design with iterative formative evaluation, and conducting summative evaluation that validates the user interface for the specified users in the specified use environments — that together produce the Usability Engineering File (UEF). The UEF is the evidence package an inspector or Notified Body opens to judge whether use-related risk has been engineered out of the device rather than blamed on the user.

The standard is recognised by the FDA as a consensus standard; harmonised under EU MDR/IVDR via Annex I §5 (general requirements on safety and performance including ergonomic considerations) and §22 (devices intended for use by lay persons); embedded in MDSAP audit scripts; referenced by IMDRF SaMD considerations. The companion IEC/TR 62366-2:2016 provides extensive guidance on how to apply the standard. ANSI/AAMI HE75 remains the substantive design reference for US human-factors practice.

FDA's 2016 Human Factors guidance, the 2022 draft on the content of human factors information in marketing submissions, and the FDA's published 'List of Highest Priority Devices for Human Factors Review' together established that for many devices — autoinjectors, insulin pumps, home dialysis, ventilators, automated external defibrillators, infusion pumps, surgical staplers, robotic surgery consoles, and several dozen others — a marketing submission without a complete IEC 62366-aligned human-factors validation package will not be cleared. The bar is no longer 'we have an IFU and a training course'; it is 'we ran a summative human-factors validation with representative users in representative environments, and the residual use-related risks are documented and acceptable'.

On the EU side, MDR Annex I §5.1 requires that devices be designed and manufactured in such a way that they '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'. §22 imposes additional requirements for devices intended for use by lay persons. EU Notified Bodies expect explicit IEC 62366-1 conformance — a UEF that mirrors the standard's clause structure — and reject technical documentation that handles usability as an afterthought.

Beyond compliance, use-related issues are one of the largest drivers of post-market complaints, returns and recalls. The CDRH MAUDE database and the EU EUDAMED vigilance data both show use-related events comprising a substantial fraction of reported serious incidents across high-priority device categories. Investing upstream in IEC 62366 work reduces downstream cost-of-quality more reliably than almost any other QMS investment.

§5.1 requires the manufacturer to prepare a use specification that documents: the intended medical indication; the intended patient population; the intended part of the body or type of tissue applied to or interacted with; the intended user profile (with the relevant characteristics — training, education, experience, language, dexterity, sensory abilities); the intended use environment (including, where applicable, lighting, noise, mobility, hygiene, single vs multi-patient use); and the operating principle of the device. The use specification is the foundation deliverable — every later step in the process references it.

A common failure is a use specification written in marketing language ('healthcare professionals in clinical settings') that is too vague to drive the hazard analysis or the evaluation design. The use specification should be specific enough to define who can be recruited as a representative user for summative evaluation, what environment must be simulated, and what training (if any) the validation participants will receive.

1. 5.1 Prepare use specification — intended user, use environment, indication, operating principle.
2. 5.2 Identify user interface characteristics related to safety — controls, displays, alarms, connectors, packaging, labelling, IFU, training material.
3. 5.3 Identify known or foreseeable hazards and hazardous situations — derived from the use specification, the UI characteristics, and the §5.4 primary operating functions; cross-references to the RMF.
4. 5.4 Identify and describe hazard-related use scenarios — the specific sequences of user-device interactions that could lead to harm; the dataset that drives evaluation design.
5. 5.5 Select the use scenarios for summative evaluation — typically a prioritised subset based on severity, probability and likelihood-of-detection; rationale documented.
6. 5.6 Establish the user interface specification — the documented UI design intent that the design output must implement.
7. 5.7 Establish the user interface evaluation plan — the planned formative evaluations across the lifecycle, leading to the summative evaluation protocol.
8. 5.8 Perform user interface design, implementation and formative evaluation — iterative; each iteration documented with method, participants, findings and design changes.
9. 5.9 Perform summative evaluation of the user interface — the validation activity that confirms the device can be used safely by representative users in representative environments performing the §5.5 selected scenarios.

Formative evaluations (§5.8) are exploratory activities run iteratively throughout development to identify and address use-related design issues early. Methods range from cognitive walkthroughs and expert reviews to small-N usability tests on prototypes; the goal is to find and fix problems, not to validate. Each formative evaluation is documented with method, participants (number, profile, recruitment criteria), tasks performed, findings (use errors observed, near-misses, user feedback), and the resulting design changes. Multiple formative cycles are normal — the UEF should show progression.

Summative evaluation (§5.9) is the final validation activity, performed on the production-equivalent device with the final IFU and training material, in a representative use environment, with representative users from each defined user group. The summative evaluation protocol is pre-approved and frozen; it defines the use scenarios from §5.5, the participant criteria, the recruitment plan, the environment simulation, the training (or no-training) condition, the data to be collected, the use-error classification framework and the acceptance criteria. Sample size is typically 15 per distinct user group per FDA guidance — fewer is acceptable only with statistical justification or a clearly justified scope reduction.

Common failure mode: formative work treated as a substitute for summative; or summative performed on prototypes; or summative performed on production units but with developer-led training that the actual user population would not receive. Each of these breaks the validation chain and is among the most-cited human-factors findings.

• Objectives stated against the use specification and the §5.5 selected use scenarios.
• Participant criteria for each user group — inclusion / exclusion based on training, experience, language, dexterity, sensory abilities; recruitment plan.
• Sample size justification — typically 15 per distinct user group; documented rationale for any reduction.
• Use environment specification — simulation fidelity, equipment, distractions, ambient conditions; rationale for simulated rather than actual where applicable.
• Training condition — none / per IFU / per planned training material; matched to the as-delivered condition.
• Materials — the production-equivalent device, the final IFU, the final training material, any accessories.
• Task list — the specific tasks each participant performs, mapped to the §5.5 use scenarios.
• Data collection — observation method, video / audio capture, think-aloud protocol, post-task interview, post-session interview, error classification framework, near-miss capture method.
• Pre-defined classification of observed use errors — by severity (potential harm) and by category (perception / cognition / action).
• Acceptance criteria — explicit, pre-approved; typically 'no use error of severity X without mitigation' or 'all use errors of severity Y are mitigable by labelling / training and have been'.
• Roles — moderator, observer, data recorder, analyst; their training and independence.

Each observed use error (and each near-miss) is analysed for: (a) the immediate cause from the user's perspective (perception failure, cognition failure, action failure); (b) the design contribution to the cause (insufficient labelling, confusable controls, weak feedback, missing alarms, ambiguous IFU step, training inadequacy); (c) the potential clinical harm; (d) whether the design can be modified to eliminate the cause; (e) whether labelling / training / IFU changes can mitigate; (f) the residual risk after mitigation. The analysis is documented per use error and rolled up into a residual-risk evaluation for the device under §5.9 and into the RMF under ISO 14971 §7 / §8.

The risk-control hierarchy from ISO 14971 §7.1 applies: inherent safety by design first (eliminate the use error by changing the UI), protective measures second (alarm, interlock, mistake-proofing), information for safety last (IFU, training, labels). A summative report that justifies acceptance of a serious use-error pattern by 'updating the IFU' alone — without consideration of design changes — fails the hierarchy and is a frequent finding.

Information for safety — IFU, labelling, on-device labels, training material — sits at the bottom of the risk-control hierarchy. It is acceptable as a risk control only when inherent design and protective measures have been considered and either implemented or justifiably rejected. IFU effectiveness is itself testable; the summative evaluation should reveal whether the IFU is read, understood and followed by representative users under representative conditions. An IFU change introduced after summative evaluation as a mitigation for an observed use error requires re-evaluation that the change works.

Training as a risk control is acceptable but is treated sceptically by regulators. The argument 'users will be trained, so they won't make this error' must be supported by: a documented training programme; evidence that the training reaches and is completed by the actual user population; evidence (typically from summative) that the trained user performs the task safely; and a sustainability case (refresher training, training records, distributor training reach). Lay-user devices under MDR §22 specifically constrain reliance on training because lay users typically receive no formal training.

§5.10 requires that the manufacturer establish and maintain the Usability Engineering File containing the records of the usability engineering process. A defensible UEF index references:

• Usability engineering plan (the project-specific plan with deliverables, methods, schedule, roles)
• Use specification (signed)
• User-interface characteristics analysis
• Hazard-related use-scenario analysis (with traceability to RMF hazards)
• Primary operating functions definition
• Selected use scenarios for summative evaluation, with rationale
• User-interface specification (signed)
• User-interface evaluation plan
• Formative evaluation records — protocol, results, design changes, per cycle
• Summative evaluation protocol (signed and pre-approved)
• Summative evaluation execution records — participant pool, raw observation data, use-error log
• Summative evaluation report with residual-risk evaluation and acceptance decision
• Cross-references to the RMF (hazards, controls, residual risk), the DHF (design inputs / outputs / validation), the SDF (UI software per IEC 62304) and the IFU/labelling control file

The UEF is a lifelong file — it updates as the device evolves, as post-market data reveals use-related issues, and as labelling or training changes are made. A UEF that ends at first release and is never updated is non-compliant for any device that has been on the market for more than one PMS cycle.

ISO 14971 §10 (production and post-production information) and EU MDR Article 83 PMS together require that field data feed back into the risk evaluation — and that includes use-related field data. Complaint analysis should code each complaint for use-error contribution; service and return data similarly. A pattern of use-error complaints triggers a UEF review under §5.8 / §5.9, which may trigger a design change, an IFU update, a training update or, in severe cases, an FSCA. The UEF update is itself an inspectable record; PSURs and PMS reports for higher-priority device categories routinely include a usability-evidence summary.

MDR Annex I §22 imposes additional requirements on devices intended for use by lay persons: usability designed for the lay user; risk of error reduced as far as possible; lay user can use device safely and properly at all stages of the procedure; design must enable verification by the user that the device functions properly. Practically, this means: lower assumed knowledge baseline; lower assumed dexterity baseline; broader assumed sensory variance; consideration of distraction, multitasking, emotional state (e.g. parental administration to a child in distress); explicit consideration of single-use vs reusable use cycles; explicit consideration of recovery from a use error (can the lay user notice they made an error and recover?). Lay-user devices typically require larger summative sample sizes and tighter residual-risk acceptance criteria.

• Use specification too vague to drive recruitment, environment simulation or task list.
• User groups not distinguished — single sample collapsing across users with materially different characteristics.
• Hazard-related use scenarios not traceable to the RMF.
• Selected scenarios for summative not derived from a documented prioritisation; rationale missing.
• Formative evaluations performed but not documented to a standard that supports the §5.10 UEF.
• Summative performed on prototypes rather than production-equivalent units.
• Summative performed with developer-led training that the actual user population would not receive.
• Summative sample size <15 per user group without statistical justification or scope rationale.
• Use errors observed but acceptance argued on the basis of IFU updates that have not themselves been re-evaluated.
• Risk-control hierarchy violated — labelling / training relied upon before design controls considered.
• Lay-user devices analysed against trained-user assumptions in violation of MDR §22.
• Cross-references to RMF / DHF / SDF / IFU missing or stale.
• UEF frozen at first release; post-market use-error data not flowed back.
• Training-as-risk-control claimed without evidence of training reach in the field.
• Cybersecurity-relevant UI considerations (e.g. authentication, lockout) absent despite a connected device.

• Use-spec completeness against §5.1 checklist (target 100%).
• Hazard-to-use-scenario traceability completeness (rows without scenario / scenario without RMF hazard).
• Formative evaluation cycles per major UI change (target ≥2 cycles per release).
• Summative sample-size attainment against plan per user group.
• Use-error rate per task in summative (trend across cycles).
• Residual-risk acceptance closure rate (% of residual risks signed off at release).
• Use-related complaint rate post-launch (per unit shipped).
• Use-related complaint → UEF-review opening rate.
• Time from use-related complaint cluster detection to design change / IFU update.
• UEF index completeness and currency.

V5 Ultimate models the IEC 62366-1 process as a first-class workspace inside the discrete-industry QMS, scoped per product family. The use specification is a controlled, signed document with the §5.1 fields enforced. User-interface characteristics, hazard-related use scenarios and primary operating functions are entered as structured records with explicit cross-references to the RMF (so a hazard added in the RMF surfaces in the UEF and vice versa).

Formative evaluations are scheduled, run and recorded as discrete events, each with protocol, participants, observation data, identified use errors, design-change actions and follow-up verification. The cumulative formative history is visible at a glance — a release without sufficient formative evidence is flagged before the summative protocol is signed.

Summative evaluation protocols are authored against the §5.5 selected scenarios with pre-approved acceptance criteria, frozen at sign-off, and executed with electronic capture of observations, use-error classifications and post-task / post-session data. The summative report assembles automatically from the captured data, with the residual-risk evaluation per use error linked back to the RMF for §7 risk-control verification and §8 residual-risk acceptance.

The UEF index is auto-assembled from the controlled records — no manual maintenance, no risk of a missing reference at audit. Cross-references to the DHF (design inputs / outputs / validation), the SDF (UI software per IEC 62304), the IFU / labelling control file and the RMF are live. Post-market use-error data flows in from the complaint module; a cluster opens a UEF review task that surfaces the original UEF evidence and the residual-risk acceptance for the affected scenario, accelerating the review-update-redocument cycle.

For lay-user devices, the workspace applies MDR §22 specific defaults — recruitment criteria templates for lay populations, environment simulation prompts (home, distraction, emotional state), tighter residual-risk acceptance criteria, larger sample-size targets. The same workspace serves the FDA 2016 + 2022 draft human-factors expectations and the EU MDR Annex I §5 / §22 expectations from one evidence package — no double documentation.