Written and maintained by CASRAI Editorial Board
Last updated
IEC 62366-1 is the international standard that structures usability engineering for medical devices — the documented process of designing, evaluating and validating a device’s user interface so that use errors involving safety-critical tasks are identified and controlled before the device reaches a user. Most summaries of it collapse straight to “you need a usability test.” That skips the part that actually generates findings during audit: the standard defines a fixed sequence of five activities, each of which produces a specific record in the usability engineering file (UEF), and the standard does not let you determine on your own that a use-related risk is acceptable — that determination is handed off to the device’s ISO 14971 risk management file. This page walks the sequence in order and covers that hand-off in detail, because it is the single most commonly misunderstood part of the relationship between the two standards.
Edition and status
IEC 62366-1 exists in more than one form, and treating them as interchangeable is a common sourcing mistake:
| Designation | What it is | Status |
|---|---|---|
| IEC 62366-1:2015 | The base normative standard, “Medical devices — Part 1: Application of usability engineering to medical devices.” Replaced the original single-part IEC 62366:2007. | Superseded on its own by the amended text below. |
| IEC 62366-1:2015/AMD1:2020 | Amendment 1. Narrowed the standard’s own scope for determining risk acceptability and tightened its relationship to ISO 14971 — the change this page is built around. | Current normative text is the base standard as amended. |
| IEC/TR 62366-2:2016 | An informative technical report (not a requirements document) giving guidance and worked examples for applying Part 1 — formative-evaluation methods, usability test protocols, and how to build a use specification in practice. | Companion guidance only; nothing in it is independently auditable the way Part 1’s clauses are. |
| ANSI/AAMI/IEC 62366-1 | The U.S. national adoption, tracked separately in FDA’s Recognized Consensus Standards database. | FDA recognizes the standard as a consensus standard for premarket submissions — recognition is not full equivalence to FDA’s own guidance (see the closing section below), so confirm the current recognition entry and any extent-of-recognition limitations directly against FDA’s database before citing it in a submission. |
IEC standards are copyrighted and sold, not published openly. Nothing on this page reproduces clause text — it describes what each clause requires and cites the clause number so you can check it against your own copy.
The process, in the order the standard defines it
IEC 62366-1 is not a checklist you can do in any order. Each step below consumes the output of the one before it, and the usability engineering file has to show that lineage — an auditor tracing your summative evaluation report should be able to walk backwards to the use specification it was built to validate.
1. Use specification (Clause 5.1)
The use specification is the frame for everything that follows: the device’s intended medical indication, intended patient population, intended part of the body or type of tissue interacted with, intended user profile(s) (including any assumed training, literacy, or physical/cognitive capability), intended use environment, and the operating principle. It also states whether the device is prescription-only or intended for lay/OTC use, which changes what “reasonably foreseeable” means for every later step. Get the use specification wrong or vague and every downstream deliverable inherits the error — it is the first thing a reviewer checks when a usability file doesn’t hold together.
2. User interface characteristics related to safety (Clause 5.2)
From the use specification, the manufacturer identifies the specific characteristics of the user interface — hardware controls, displays, alarms, packaging, labeling, and the instructions for use — that relate to safety, and performs a task analysis of the user tasks those characteristics support. This step is where the physical and informational design of the device gets decomposed into the discrete interactions a real user will perform, which is the raw material the hazard-identification step needs.
3. Known or foreseeable use problems (Clause 5.3–5.4)
The manufacturer then identifies known or foreseeable use problems associated with the device or with similar/predicate devices — drawn from post-market surveillance data, complaint files, adverse event literature, and use-error data on comparable products already on the market. This is where usability engineering explicitly reaches outside the device under development: a novel interface with no direct predecessor still has to account for use-error patterns documented for the class of device it belongs to.
4. Hazard-related use scenarios (Clause 5.5–5.6)
Combining the safety-related UI characteristics with the known/foreseeable use problems produces a list of hazard-related use scenarios — specific descriptions of how a use error involving a given task could lead to harm. Manufacturers identify which of these involve critical tasks: tasks that, performed incorrectly or omitted, could cause serious harm. Critical tasks are what the rest of the usability engineering effort exists to control, and the file has to document the rationale for every critical-task determination, not just the conclusion.
Formative evaluation runs alongside and after this step (Clause 5.7–5.8) — iterative usability assessments, from expert/heuristic review through simulated-use testing with representative users on prototypes — used to find and redesign around use problems before the design is frozen. IEC 62366-1 does not itself mandate formative testing as a discrete, named deliverable the way FDA’s own guidance does; in practice almost every manufacturer runs it anyway, because it is the only realistic route to a summative evaluation that passes.
5. Summative evaluation (Clause 5.9–5.11)
Summative evaluation is the final, formal usability validation: representative users, drawn from the intended user population(s) defined in the use specification, performing the identified critical tasks on the final (or equivalent) device design and labeling, in a simulated or actual use environment, without coaching beyond what the actual labeling and training would provide in the field. The evaluation has to be planned in advance — acceptance criteria and pass/fail rationale defined before testing starts, not fitted afterward — and any use errors or “close calls” observed have to be analyzed for root cause, not simply tallied.
Where 62366-1 hands off to the 14971 risk file
This is the point Amendment 1:2020 exists to clarify, and it is the most consequential change in the standard’s history. The base 2015 text could be read as letting a manufacturer conclude, from summative evaluation results alone, that a use-related risk was acceptable. AMD1:2020 removed that reading. As amended, IEC 62366-1 identifies and evaluates use-related hazards — it does not itself determine that a residual risk is acceptable. Any use-related risk that summative evaluation does not fully mitigate has to be carried into the device’s ISO 14971 risk management file, where it is dispositioned through the same severity/probability/benefit-risk framework as every other hazard on the device — mechanical, electrical, biological, or software.
Practically, that means a compliant usability engineering file and a compliant risk management file are not two independent deliverables that happen to reference each other — they share data in both directions. The use-related hazards identified in 62366-1 Clause 5.4/5.5 populate hazard entries in the 14971 file; the risk file’s benefit-risk determination is what actually closes out whether a use error found in summative testing is acceptable, not the usability report itself. A usability engineering file that reaches a self-contained “acceptable” conclusion without a corresponding entry in the risk management file is exactly the kind of gap a notified-body or FDA reviewer is trained to find.
What IEC 62366-1 is not
- Not a testing-methods cookbook. Study designs, sample-size reasoning, and worked examples live in the informative IEC/TR 62366-2, not in the normative Part 1 clauses summarized above.
- Not a software lifecycle standard. If the device (or a component of it) is software, the development, verification, and configuration-management records are governed separately by IEC 62304 — usability engineering and software lifecycle management are parallel, cross-referenced processes, not one process.
- Not the same document as FDA’s own human factors guidance. FDA recognizes IEC 62366-1 as a consensus standard, but FDA’s Applying Human Factors and Usability Engineering to Medical Devices guidance is more prescriptive in places — notably, it expects documented formative testing ahead of summative testing as a matter of course, where 62366-1 itself does not name that as a discrete required deliverable. Recognition of a standard is not full equivalence to FDA’s expectations for a specific submission.
- Not a substitute for a quality management system. The usability engineering process described here is one input the device’s QMS has to capture as a controlled process, per ISO 13485 and, for FDA-regulated devices, 21 CFR Part 820 (transitioning to the QMSR).
Frequently asked questions
What is IEC 62366-1?
IEC 62366-1 is the international standard specifying the usability engineering process manufacturers must apply to medical devices: defining intended use and users, identifying safety-related interface characteristics and foreseeable use problems, deriving hazard-related use scenarios, and validating the design through summative evaluation.
Does IEC 62366-1 replace ISO 14971?
No. IEC 62366-1 identifies and evaluates use-related hazards; as amended by AMD1:2020, the determination of whether a residual use-related risk is acceptable happens in the device’s ISO 14971 risk management file, not inside the usability engineering process itself.
What is the difference between formative and summative evaluation?
Formative evaluation is iterative testing during design — expert review through simulated-use testing on prototypes — used to find and fix use problems before the design is finalized. Summative evaluation is the single, final, formally planned validation study on the finished (or equivalent) design, used to demonstrate that critical tasks can be performed safely by representative users.
Is IEC 62366-1 the same as FDA’s human factors guidance?
They cover the same underlying process and FDA recognizes IEC 62366-1 as a consensus standard, but they are not identical documents. FDA’s own guidance is more prescriptive in places — for example, expecting documented formative testing before summative testing as standard practice, which 62366-1’s text does not itself mandate as a named deliverable.
What goes in a usability engineering file?
At minimum: the use specification, the analysis of user-interface characteristics related to safety and the associated task analysis, the list of known/foreseeable use problems and hazard-related use scenarios with critical-task determinations and rationale, formative evaluation records, and the summative evaluation plan, protocol, and results with root-cause analysis of any use errors observed.
