For Software as a Medical Device (SaMD), the user interface is not a layer on top of the device. It is the device. A clinician reading a flagged result, a patient responding to an alert, a nurse interpreting a dashboard — each of these interactions is where the software either delivers its clinical benefit or creates a hazard. That is why IEC 62366 matters as much to software teams as to the hardware manufacturers it is more often associated with.
This guide explains what IEC 62366 requires, how the usability engineering process works in practice, how use-related risk connects to ISO 14971, and what a SaMD team should have in place. It closes with a readiness checklist and answers to the questions teams most often ask.
Note: This guide provides general educational information, not legal or regulatory advice. Requirements, market authorization pathways, and expectations vary by device, market, and regulator. Confirm the applicable standard editions, amendments, and requirements for your product and target markets.n
What Is IEC 62366?
IEC 62366 is the international standard for applying usability engineering to medical devices. Its purpose is to help manufacturers identify and reduce risks that arise from how a device is used, rather than from how it fails. The current structure separates the normative process, published as IEC 62366-1, from the accompanying guidance, published as the technical report IEC/TR 62366-2, which offers practical direction on applying the process.
The distinction that matters most is this: IEC 62366 is not about making a device pleasant to use. It is a safety standard. Its subject is use-related risk, the possibility that a correct-but-misunderstood interface, an ambiguous alert, an unclear workflow, or a foreseeable misuse leads to harm. A device can function exactly as designed and still be unsafe if users routinely misread it.
The standard generally applies to medical devices, including software. Two points about its regulatory status are worth understanding because they vary by market and change what the standard does for you.
Regulatory Status: Recognized by FDA, Not Currently Harmonized in the EU
In the United States, FDA lists IEC 62366-1 in its Recognized Consensus Standards database. In practice, this means a manufacturer can submit a Declaration of Conformity to the standard to support part of a premarket review, rather than explaining its entire usability engineering approach from first principles. The declaration does not replace the underlying evidence and documentation, but it can streamline how that work is presented. FDA also publishes separate guidance on applying human factors and usability engineering to medical devices, which sets out what reviewers typically expect to see, including formative studies and summative validation testing.
In the European Union, the position is different. IEC 62366 is not on the EU MDR harmonized standards list, so conformity with it does not carry a presumption of conformity with the regulation as a harmonized standard would. Teams commonly apply it as state-of-the-art usability engineering support instead. Harmonization lists are updated periodically, so confirm the current status for your target market rather than assuming it.
Usability Engineering Terms SaMD Teams Should Distinguish
Term | Practical meaning |
Use specification | A description of the intended users, uses, use environments, and patient population for the device |
User interface | Everything through which the user and the device exchange information, including screens, alerts, inputs, outputs, and accompanying documentation |
Use error | A user action or lack of action that leads to a result different from what the manufacturer intended or the user expected |
Hazard-related use scenario | A use scenario that could lead to a hazardous situation or harm, and therefore requires evaluation |
Formative evaluation | Usability evaluation performed during development to explore and improve the design |
Summative evaluation | Usability evaluation performed at the end of development to assess whether the design supports safe use |
Usability engineering file | The set of records demonstrating that the usability engineering process was applied |
One clarification worth making early: “use error” is not the same as “user error” in the blaming sense. The standard treats a use error as a signal about the design, not a failure of the person. If users predictably make the same mistake, the interface is the thing to fix.
Why IEC 62366 Matters More for Software Than Teams Expect
Most published guidance on IEC 62366 is written with hardware in mind: physical controls, connectors, labels, sterile packaging, and the physical environment of use. That framing understates how central usability is for SaMD.
For a software device, almost every risk control reaches the patient through the interface. If the software detects a condition, a human must notice, understand, and act on it. If the software calculates a dose or flags a trend, how that output is presented determines whether it is used correctly. The clinical value of SaMD is delivered through the user interface, which means use-related risk is not a side category of risk. It is often the main one.
This is not a theoretical concern. Design issues have long been among the leading causes of medical device recalls, and published research examining recalls between 2012 and 2015 identified several hundred device recalls attributed to user interface software errors. As the share of device function delivered through software has grown, the interface has become a correspondingly larger source of use-related risk.
Use-Related Risks Specific to Software
A usability analysis for SaMD should consider risks that hardware-oriented guidance rarely covers:
- Alert and alarm design, including alert fatigue when notifications are frequent or low-value, and missed alerts when they are too subtle
- Automation bias, where users accept a software output without the independent judgment the intended use assumes
- Ambiguous presentation of uncertainty, confidence, or model limitations, particularly for AI-enabled software
- Workflow mismatch, where the software assumes a sequence of steps that does not match how clinicians actually work
- Data-context errors, such as acting on stale, partial, or wrong-patient data because the interface does not make context obvious
- Interpretation of results by users with different training, from specialist clinicians to patients using a consumer-facing app
- Variation across devices, screen sizes, operating systems, and network conditions that changes what the user actually sees
- Accessibility and use environment factors, including glare, interruption, urgency, and one-handed use
- Configuration and settings that allow the device to be used outside its intended use without the user realizing it
The IEC 62366 Usability Engineering Process
The standard describes usability engineering as a process integrated into development rather than a test performed at the end. The following sequence gives SaMD teams a practical model.
1. Define the Use Specification
Start by documenting who will use the device, for what, on whom, and where. For SaMD, this should include user groups and their training, the clinical or personal context, the operating environment, the devices and platforms involved, and the patient population. The use specification anchors everything that follows, because a risk that matters for a patient-facing app may not matter for a specialist reading a workstation display.
2. Identify User Interface Characteristics Related to Safety
Identify the parts of the interface that carry safety significance: the alerts, the primary outputs, the confirmations, the inputs where an error could propagate, and the safety information. Not every screen is safety-related, and separating the safety-related parts keeps the effort proportionate.
3. Identify Known and Foreseeable Hazards and Use Errors
Consider what is already known. Published literature, adverse-event databases, complaints about predicate or similar devices, prior versions of your own product, and support tickets are all useful sources. Known use problems with comparable devices are among the most valuable inputs available, because they describe errors real users have actually made.
4. Identify Hazard-Related Use Scenarios
Turn the hazards into concrete scenarios. A hazard-related use scenario describes a realistic sequence: the user is in a particular situation, the interface presents specific information, the user either acts or does not act, and harm becomes possible. Vague statements, such as “the user may misread the screen,” are not enough. The scenario should be specific enough to test.
It is worth knowing that FDA human factors guidance frames much of this same work in terms of critical tasks, meaning tasks that could result in serious harm if performed incorrectly or not performed at all. The vocabularies map closely: identifying hazard-related use scenarios under IEC 62366 and identifying and categorizing critical tasks under FDA human factors guidance are largely the same analytical exercise described in different language. Teams preparing for a US submission should document which tasks are critical and the rationale for that designation, because reviewers look for exactly that.
5. Select the Scenarios for Summative Evaluation
Not every scenario requires formal evaluation. Teams should select the hazard-related use scenarios that matter most for safety and document the rationale for the selection, including why other scenarios were not selected.
6. Specify the User Interface and Design With Usability in Mind
Document the user interface specification, including the safety-related elements and the accompanying documentation. Then design against it. In SaMD, this is where usability and risk control meet directly, because interface decisions frequently are the risk controls: a confirmation step, a constrained input, a clearer label, a safer default, a visible data-context indicator.
7. Perform Formative Evaluation Through Development
Formative evaluation is exploratory. It happens during design, with prototypes or partial builds, and its purpose is to find problems while they are still cheap to fix. For software teams, this fits naturally into iterative development and is far more effective than discovering a use problem after the interface has been built and validated.
8. Perform Summative Evaluation
Summative evaluation assesses whether the final design supports safe use. It involves representative users from each user group performing the selected hazard-related use scenarios in conditions that reasonably reflect actual use. Results should be analyzed for use errors and difficulties, and any findings with safety significance should feed back into the design and into risk management.
9. Compile and Maintain the Usability Engineering File
The usability engineering file is the record demonstrating that the process was applied. It typically contains or references the use specification, the safety-related interface characteristics, the identified hazards and use errors, the hazard-related use scenarios, the evaluation plans and results, and the conclusions on safe use. Like the risk management file, it should stay current as the product changes.
How IEC 62366 Connects to ISO 14971 and IEC 62304
Usability engineering does not stand alone. Use-related risk is a category of risk, so IEC 62366 feeds directly into the ISO 14971 risk management process rather than running beside it. Hazards identified through usability work belong in the risk management file, and risk controls that take the form of interface changes belong in both.
Standard or record | Relationship to usability engineering |
ISO 14971 risk management | Use-related hazards feed the risk analysis; interface risk controls are evaluated and verified as risk controls |
IEC 62304 software lifecycle | Interface risk controls become software requirements, design outputs, and verification activities |
ISO 13485 quality management system | Provides the organizational framework, design controls, and record control the usability process operates within |
Design History File | Holds or references the usability records alongside design and risk evidence |
In practice, this means a use-related hazard identified in a formative session should become a documented hazard, a design change, a software requirement, a verification test, and a traceable link between all of them. A usability finding that never reaches the requirements is a finding that was not acted on.
Common IEC 62366 Mistakes in Software Teams
Treating usability as user experience polish
Usability engineering under IEC 62366 is about safety, not satisfaction. A beautiful interface that users misread is a usability engineering failure. The two goals often align, but they are not the same, and the standard concerns the safety one.
Running summative evaluation as the only usability activity
A single validation session at the end tells you whether the design works, by which point it is too late to change it cheaply. Formative work through development is where use problems are actually found and fixed.
Testing with the wrong users
Evaluations should involve representative users from each defined user group. Internal staff, engineers who built the product, and clinicians who already know the software are not representative, and their results can create false confidence.
Writing scenarios too vaguely to test
A hazard-related use scenario needs to be specific enough that someone can perform it and observe whether a use error occurs. Broad statements about possible misunderstanding cannot be evaluated.
Fixing use errors with training and labeling first
Safety information has its place, but the same hierarchy that governs risk control applies here. Designing the error out is more effective than warning about it. Reaching for a warning first is usually a sign that the design question has not been asked.
Letting the usability file go stale
Software changes frequently. An interface change, a new alert, a workflow revision, or a new user group can all affect use-related risk. The usability engineering file should be updated when the design or use specification changes, not only at release.
IEC 62366 Readiness Checklist for SaMD Teams
Use this as a planning and readiness review. The appropriate depth and evidence depend on the device, its intended use, its risk profile, and the applicable regulatory expectations.
# | Checklist item | What supporting evidence typically looks like |
1 | Use specification documented | Defined user groups, uses, use environments, platforms, and patient population |
2 | Safety-related user interface characteristics identified | Documented identification of the interface elements that carry safety significance |
3 | Known use problems reviewed | Review of literature, adverse-event data, complaints, and prior-version or similar-device issues |
4 | Hazards and use errors identified | Use-error analysis covering normal use and reasonably foreseeable misuse |
5 | Hazard-related use scenarios defined | Specific, testable scenarios linking use situations to potential harm |
5b | Critical tasks identified and categorized | List of tasks that could cause serious harm if performed incorrectly, with documented rationale |
6 | Scenarios selected for summative evaluation with rationale | Documented selection and the reasoning for inclusion and exclusion |
7 | User interface specification established | Specification covering safety-related elements and accompanying documentation |
8 | Formative evaluation performed during development | Session plans, findings, and the design changes that followed |
9 | Summative evaluation performed with representative users | Protocol, participant characterization by user group, results, and analysis of use errors |
10 | Use-related hazards integrated into risk management | Use-related hazards present in the risk management file with evaluated risk controls |
11 | Interface risk controls implemented and verified | Software requirements, design outputs, and verification results for each interface control |
12 | Traceability maintained across usability, risk, requirements, and tests | Bidirectional links from use scenario to hazard to control to requirement to test result |
13 | Usability engineering file compiled and controlled | Organized file or index with version control and current contents |
14 | Conclusions about safe use documented | Documented rationale that the design supports safe use for the intended users and uses |
15 | Update triggers defined for design and use changes | Defined conditions for revisiting usability work when the interface, workflow, or user groups change |
Frequently Asked Questions
What is IEC 62366?
IEC 62366 is the international standard for applying usability engineering to medical devices. It defines a process for identifying use-related hazards, analyzing how users could make errors that lead to harm, designing the user interface to reduce those risks, and evaluating whether the final design supports safe use.
What is the difference between IEC 62366-1 and IEC 62366-2?
IEC 62366-1 contains the normative usability engineering process that manufacturers apply. IEC/TR 62366-2 is a technical report that provides guidance and practical direction for applying that process. The first states what is required; the second helps teams do it.
Does IEC 62366 apply to Software as a Medical Device?
Usability engineering applies to medical devices including software. For SaMD, this is often especially significant because the user interface is how the software delivers its clinical function, meaning use-related risk can be central rather than peripheral. Confirm the applicable requirements for your device and markets.
What is a use error under IEC 62366?
A use error is a user action, or lack of action, that produces a result different from what the manufacturer intended or the user expected. The standard treats use error as information about the design rather than as a fault of the user, which is why predictable use errors call for design changes.
What is the difference between formative and summative usability evaluation?
Formative evaluation happens during development to explore and improve the design while changes are still inexpensive. Summative evaluation happens at the end of development to assess whether the final design supports safe use, using representative users performing the selected hazard-related use scenarios.
What goes in a usability engineering file?
A usability engineering file typically contains or references the use specification, safety-related interface characteristics, identified hazards and use errors, hazard-related use scenarios, evaluation plans and results, design changes, and the conclusions about safe use. It should be maintained as the product changes.
How does IEC 62366 relate to ISO 14971?
Use-related risk is a category of risk, so usability engineering feeds the ISO 14971 process. Hazards found through usability work belong in the risk management file, and interface changes made to reduce use-related risk are evaluated and verified as risk controls.
Is usability engineering the same as user experience design?
No. Usability engineering under IEC 62366 is a safety activity focused on preventing use errors that could lead to harm. User experience design is concerned with satisfaction, efficiency, and appeal. The goals often overlap, but a design can be well liked and still unsafe.
Is IEC 62366 required by law?
The standard itself is not law. Regulators nonetheless expect a sound usability engineering process, and FDA recognizes IEC 62366-1 as a consensus standard that can be used to support a premarket submission. In the EU, it is generally applied as state of the art rather than as a harmonized standard. Confirm the expectations that apply to your device and markets.
How Sequenex Supports Usability-Informed SaMD Development
Usability engineering works best when it is part of how software is built rather than a study run before submission. Interface decisions, risk controls, requirements, and verification evidence should move together, so a use-related finding becomes a design change with a traceable record behind it.
Sequenex builds medical device software under an ISO 13485-certified quality management system, with the requirements, traceability, and verification records that usability and risk activities depend on. To discuss how this applies to your product, explore our SaMD development services or get in touch.
