What Is IEC 62366? Usability Engineering for Medical Devices

FDA finalized a companion guidance on marketing submission content in May 2026 and revised the 2016 human factors guidance itself in August, and neither change altered what IEC 62366-1 requires. A usability engineering file can satisfy clause 5 activity by activity and still come back from a 510(k) or premarket approval (PMA) review with a deficiency letter. The ISO 14971 risk file and the hazard-related use scenario list are two records of one phenomenon, kept by two teams, and nothing in either process forces them to agree.

IEC 62366-1 is a recognized consensus standard for US submissions and absent from the current EU harmonised standards list, so conformity to it doesn’t mean the same thing in both markets. This guide covers why the standard’s US and European status differ, the clause 5 activities that produce the file, and where those two records drift apart.

What IEC 62366-1 Covers

IEC 62366-1 specifies a process to analyze, specify, develop, and evaluate the usability of a medical device as it relates to safety. Correct use and use error together make up normal use, both inside the standard’s scope. A use error is an unintentional action or omission that produces an outcome the manufacturer didn’t intend.

Abnormal use is an intentional violation, such as conscious disregard of contraindications or sabotage. The standard can identify it but doesn’t assess or mitigate it. IEC 62366-1:2015 with Amendment 1, published June 17, 2020, remains the edition in force. The 2020 amendment also renamed “action error” to “physical mismatch,” meaning a use error caused by a physical limitation in performing a task.

Part 1 is the normative standard, the one a Declaration of Conformity points at. IEC/TR 62366-2 is a Technical Report carrying worked examples and method guidance, and it contains no requirements. Citing Part 2 as evidence of conformity is a mistake that surfaces during notified body review.

FDA Recognition and EU MDR Status of IEC 62366

The same standard does different regulatory work on each side of the Atlantic. IEC 62366-1 Edition 1.1 is a recognized consensus standard for US submissions under recognition number 5-129. The US adoption comes from ANSI and AAMI as ANSI/AAMI/IEC 62366-1:2015+AMD1:2020. The QMSR has been in effect since February 2, 2026 and incorporates ISO 13485:2016 into Part 820 by reference, so usability work also reaches FDA through the design and development requirements it now points at.

EN IEC 62366-1, including EN 62366-1:2015+A1:2020, is absent from the current EU MDR harmonised standards list. The standard therefore confers no presumption of conformity under Article 8(1). IEC 62366-1 is still how you document generally acknowledged current technical practice.

The obligation itself comes from Annex I. It requires manufacturers to reduce ergonomic and use-environment risks as far as possible, and to account for users’ training and physical condition, or on lay-use devices their skills and means. Neither the MDR nor the IVDR uses the words “use scenario” or “critical task” anywhere in its text. The EU obligation is therefore wider than the standard’s vocabulary, and applying IEC 62366-1 only to professional users leaves lay-use devices outside it.

How FDA’s 2026 Human Factors Updates Affect the Usability Engineering File

Both of FDA’s human factors guidances changed in 2026, and the changes land on what a marketing submission carries while the clause 5 activities stay as they were. The agency finalized Content of Human Factors Information in Medical Device Marketing Submissions on May 29, 2026, then revised the 2016 guidance on August 3, 2026 for the first time since issue, deleting Appendix A with its eight-section report outline and redirecting Section 9 on documentation to the new guidance.

The submission guidance sorts filings into three HF Submission Categories, and the category a manufacturer claims decides how much of the file travels with the application:

HF Submission Category	Applies to	What the submission carries
Category 1	Modified devices where the modification does not affect the human factors considerations	Conclusion and high-level summary of the HF evaluation
Category 2	No critical tasks are identified or critical tasks exist/are affected but a rationale supports not submitting HF validation testing	Rationale for the Category 2 determination, plus the recommended HF information
Category 3	FDA’s risk-based assessment indicates HF validation test data should be submitted	Comprehensive HFE/UE report including HF validation testing

Category 3 is where the two records have to agree in public. The guidance rests the category claim on the use-related risk analysis, and on traceability between that analysis and the design decisions it drove. The revised eSTAR templates have prompted for the category since August 1, 2026, which is also the date from which FDA expects the newly recommended content.

The IEC 62366-1 Usability Engineering Process, Step by Step

Clause 5 numbers nine activities, 5.1 through 5.9, and every one of them leaves a record in the Usability Engineering File (UEF):

• Prepare the use specification: The intended medical indication, patient population, body part or tissue, user profiles with assumed training and physical or cognitive capability, use environment, and operating principle.
• Identify safety-related user interface characteristics: The hardware controls, displays, alarms, packaging, labeling, and instructions for use that bear on safety.
• Identify known and foreseeable hazards: Hazards drawn from the use specification, comparable devices, and identified use errors go in the risk management file. Device failures are handled separately.
• Identify and describe hazard-related use scenarios: Each scenario documents the tasks and their sequence, records severity of harm, and links to a potential use error.
• Select scenarios for summative evaluation: Every scenario selected carries a justification, and so does every scenario left out.
• Establish the user interface specification: All testable technical requirements for the interface, whether accompanying documents exist, and whether training is necessary.
• Establish the evaluation plan: Methods, participant criteria, test conditions, and acceptance inputs for all formative and summative evaluations, defined before testing starts.
• Perform design, implementation, and formative evaluation: Expert reviews, cognitive walkthroughs, and simulated-use tests surface unanticipated use errors while there is still time to change the design.
• Perform summative evaluation: Objective evidence of safe use, with root cause analysis of every use error and close call. A tenth sub-clause, 5.10, covers an interface inherited from an earlier product.

Formative vs. Summative Evaluation Under IEC 62366-1

IEC 62366-1 requires summative evaluation but treats formative evaluation as optional, and FDA guidance expects it anyway. FDA’s position is that if no formative evaluation runs and the validation study then finds design flaws, that study was the formative evaluation. Four differences decide how a reviewer reads each study:

Dimension	Formative Evaluation	Summative Evaluation (HF Validation)
Purpose	Explore and improve the UI design	Confirm the final UI supports safe use and validate risk controls
Timing	During development, iteratively	End of development, on the final or equivalent design
Mandatory under IEC 62366-1	No	Yes

FDA applies four conditions to a summative evaluation:

• Representative participants: Participants must represent the actual intended users in each distinct user population.
• Critical tasks: Cover every critical task selected for the summative evaluation.
• Final UI: Use the final design with its labeling, packaging, and training.
• Realistic conditions: Set conditions realistic enough to stand in for actual use. The agency expects at least 15 participants from each distinct user population, and more for some device types. Manufacturers’ own employees should not be test subjects. IEC 62366-1 names no number at all, so the manufacturer still has to justify what counts as objective evidence.

A failed summative evaluation sends the design back to iterative work until it is ready for another one. A change to the interface after a passing result does the same, and that is the easy one to miss. Changes made before the result stay inside the iterative process.

How Usability Work Feeds the ISO 14971 Risk File

Since Amendment 1:2020, the link between IEC 62366-1 and ISO 14971 runs both ways. Hazard-related use scenarios feed the ISO 14971 risk table, and new hazards from risk analysis are checked back against the Hazard-Related Use Scenario (HRUS) list. The amendment also put abnormal use inside ISO 14971’s scope, which is where a hazard the usability process can name but not assess belongs.

FDA calls the use-related portion of that risk management file the Use-Related Risk Analysis (URRA), a label IEC 62366-1 doesn’t use. The summative evaluation supplies the objective evidence for judging residual use-related risk acceptable. The UEF should therefore trace each selected HRUS from the use specification through the URRA, risk control, and summative evidence.

Risk controls follow a hierarchy of inherent safe design first, then protective measures, then information for safety and labeling. Amendment 1 placed training at the third priority beside information for safety, so a training-dependent control needs documented rationale and evidence rather than an assertion. A file where labeling is the primary control without evidence the higher tiers were evaluated first hasn’t established that hierarchy.

Where Usability Engineering Files Fail Review

Files fail where the two risk records stop agreeing. The ISO 14971 risk file is usually built around failure modes and owned by the risk team. The hazard-related use scenario list is built from task analysis and owned by the human factors team. Nothing in either process forces the two to reconcile, so they are reconciled by hand, late, and a mismatch that survives into the submission can come back as a deficiency letter and another review cycle. Reviewers flag four further patterns:

• Use specification completeness: An incomplete use specification may omit user groups such as home caregivers on a home-use device, retain outdated environment descriptions, or define a UI scope that no longer matches the design.
• Orphan use errors: Use errors with no hazard connection, or hazards with no use error traced to them, signal a URRA assembled after the fact.
• Scenario selection rationale: Justifications for excluded scenarios must address severity of harm in the relevant clinical and patient context.
• Untested labeling claims: A labeling or instructions-for-use change offered as a risk control needs the same supporting evaluation as an interface change. Reviewers also look for design and development records showing every design input was verified, and a file that cannot produce that chain adds review cycles.

How Jama Connect Supports IEC 62366 Usability Engineering

Keeping the risk file and the use scenario list in agreement is a tooling problem before it is a discipline problem. Jama Connect® is a web-based requirements management and traceability platform with a pre-built medical device framework. Its Traceability Information Models (TIMs) hold the use specification, the hazard-related use scenarios, the URRA entries, the user needs above them and the risk controls and summative evidence below them in one structure. When a required downstream item is missing, the model flags it, which is how an orphan use error surfaces before a reviewer finds it. Those records sit in the Product Context Layer, one governed record spanning requirements, risks, tests, models, verification evidence, and change history.

Formal sign-off runs through Review Center, which provides 21 CFR Part 11 electronic signatures and makes the approval record auditable. Suspect flagging in Live Traceability™ surfaces every downstream record that needs reassessment when the interface changes after a passing summative evaluation. Without it, a team learns a re-evaluation was owed during the audit.

Anything done with AI inside Jama Connect is versioned and documented as AI-generated. The audit trail records what was generated, when, and against which requirement. No such record exists when AI work happens outside the governed system.

Keeping the Usability Engineering File Current as Devices Add AI

Usability assumptions and evidence have to stay current as the behavior of an AI-enabled interface changes, and the standards are behind the devices. A proposed IEC 62366-3 Technical Specification would add guidance, not requirements, on applying usability engineering to AI and machine learning. The Good Machine Learning Practice guiding principles already ask manufacturers to weigh how the human and the model perform together, which in practice means interpretability to the person acting on the output. Use specifications for AI-enabled software will need to capture those user characteristics, and a hazard-related use scenario has to describe how a clinician detects an unexpected output, interprets it, and acts on it.

Once the model behind an interface can change between releases, usability evidence stops being a submission artifact and becomes a release artifact. Every release has to record either why the existing evidence still holds or why a new evaluation was run. If your team is rebuilding that chain by hand before every submission, you can start a free 30-day trial today.

Frequently Asked Questions About IEC 62366

How many participants does a summative evaluation need?

IEC 62366-1 names no number, but FDA does. Its human factors guidance expects at least 15 participants from each distinct user population and notes the minimum can be higher for some device types. Settle the group definitions in the usability engineering plan before recruitment starts, since that is where reviewers push first. Plan against 15 for each group you define.

Does IEC 62366-1 apply to software as a medical device?

Software as a Medical Device meets the device definition under both FDA and EU MDR, so it is in scope. For SaMD the process applies to decision-support and alerting workflows, not physical controls, and the interface specification can be folded into the software requirements specification you already maintain for IEC 62304.

What is a UI of unknown provenance under IEC 62366-1?

A User Interface of Unknown Provenance (UOUP) is an interface, or part of one, developed earlier without adequate usability engineering records. For an unmodified UOUP, the normative Annex C allows a shorter route covering use specification, a review of post-production data for use errors, hazard identification, risk control, and residual risk evaluation, and omitting formative and summative evaluation. Any part you modify falls back under the full clause 5 process. The modified and unmodified parts of one interface then carry different evidence, and something has to record which is which.

How does IEC 62366-1 apply to combination products?

A combination product needs a use-related risk analysis covering the whole product, not the device constituent alone. The analysis sits inside the same verification and validation chain as the rest of the design record. FDA’s combination-product human factors guidance remains the one to follow, because the marketing-submissions guidance says combination products are not addressed there.

This article was authored by Tom Rish on September 14, 2026.