IEC 62366-1

What IEC 62366-1 covers

The full title of IEC 62366-1 is “Medical devices - Part 1: Application of usability engineering to medical devices”. It specifies how manufacturers must design, evaluate and document the user interface of a medical device so that use-related hazards are reduced to an acceptable level.

The scope is narrower than many development teams initially assume: The standard does not require an aesthetically pleasing or particularly comfortable operating sequence. It requires evidence that foreseeable use errors do not lead to harm for patients, users or third parties. Usability aspects without a safety relevance are formally outside the normative scope, even if they can be decisive for acceptance and market success.

All medical devices are addressed, regardless of risk class and technology: from the disposable syringe to software as a medical device to the ventilator.

The standard is not a substitute for human factors engineering but its regulatory implementation for medical devices.

The usability engineering process according to clause 5

The core of the standard is the process described in clause 5. It proceeds in consecutive steps, each of which forms the basis for the next:

• Use specification: Intended use, intended user groups, use environment and patient population are defined in a binding way.
• Safety-related characteristics: Characteristics of the user interface with a safety relevance, as well as known and foreseeable hazards, are identified.
• Known usability problems: Insights from predecessor products, literature, vigilance data and post-market surveillance are systematically taken into account.
• Hazard-related use scenarios: Scenarios that can lead to a hazardous situation are derived and described. From them, the scenarios to be tested in the summative evaluation are selected. For FDA submissions, critical tasks are often derived from them in addition.
• Selection for the summative evaluation: From these scenarios, what is finally tested is selected with a documented rationale.
• User interface specification: The requirements are laid down in a testable way. It forms the central link between analysis, design requirements and later verification.
• Evaluation plan: Formative and summative activities are planned in advance.
• Design, implementation and formative evaluation: Iterative improvement during development.
• Summative evaluation: Final demonstration with representative users under realistic conditions.

What matters is traceability: Each step must visibly build on the previous one and be documented in the usability engineering file. A summative evaluation whose tested scenarios cannot be traced back to a documented risk analysis does not meet the requirement, regardless of how carefully it was carried out.

Key terms of the standard

IEC 62366-1 defines a number of terms precisely and in part differently from general usage. Three distinctions are particularly relevant in practice:

• Use error vs. abnormal use: A use error leads to a result different from the one intended, without any intent being attributed to the user. Abnormal use, in contrast, is deliberate action against the intended use and does not have to be controlled by the manufacturer through design.
• User interface: Covers not only displays and controls but also labeling, packaging, alarms and the instructions for use.
• Hazard-related use scenario: Not every use scenario is safety-relevant. Only scenarios with a possible link to harm are the subject of the normative evidence.

Interplay with risk management

IEC 62366-1 is not a stand-alone procedure but closely interlinked with risk management according to ISO 14971. The standard provides the use-related perspective on risks, which a purely technical failure analysis does not cover.

Specifically: The use-related risk analysis links tasks, possible use errors, resulting hazardous situations and potential harm. Its results feed into the risk management file; conversely, risk management provides the acceptance criteria against which the summative evaluation is assessed. Both files must be consistent. Contradictions between the usability engineering file and the risk management file are among the most frequent audit findings.

Regulatory status: MDR, IVDR and FDA

A common misconception needs to be cleared up here: IEC 62366-1 is currently not listed as a harmonized standard under the MDR (Regulation (EU) 2017/745) in the Official Journal of the EU. A formal presumption of conformity can therefore not be derived from its application.

In practice, this changes little about its significance. Annex I of the MDR contains several usability-related provisions in the general safety and performance requirements, including those on reducing risks from use errors and on ergonomic design. IEC 62366-1 is the established way to meet these requirements and is regarded as the recognized state of the art. Notified bodies generally expect evidence according to this standard or a robust justification for a different approach. The same applies by analogy to the IVDR.

In the United States, the FDA human factors guidance sets out its own, in part more far-reaching expectations, for example the explicit identification of critical tasks and the submission of an HFE/UE report. A process set up according to IEC 62366-1 covers large parts of this but does not replace the FDA-specific preparation. The FDA also lists IEC 62366-1 as a recognized consensus standard (recognition number 5-129 for Edition 1.1 of 2020, announced in the Federal Register on March 3, 2021).

IEC 62366-1 and IEC 62366-2 compared

The two parts are often confused. IEC 62366-1 is the normative requirement: It states what has to be demonstrated. IEC 62366-2 is a technical report without normative character: It states how to proceed methodically and contains guidance on user research, test design and analysis. Audits are conducted against Part 1; Part 2 is an aid, not an obligation.

Common mistakes in implementation

• Usability engineering at the end of development: If the summative evaluation is planned only shortly before approval, design changes can hardly be implemented any more. The process must accompany development, not conclude it.
• Use specification defined too broadly: Anyone who includes every conceivable user group must also cover all of them in the summative evaluation. A precise delimitation considerably reduces the testing effort.
• Missing traceability: Tested scenarios without a documented link to the risk analysis are worthless from an audit perspective.
• Confusing formative and summative: A formative study with the final device is not a summative evaluation as long as planning, sample and acceptance criteria do not meet the validation standard.
• Residual risks without root cause analysis: Merely counting observed use errors is not enough. A root cause analysis is required for each incident.
• Insufficiently defined user groups: If user groups, user profiles or recruitment criteria are not defined robustly, the validity of later evaluations is in question.

Frequently asked questions (FAQ)

Sources

• IEC 62366-1:2015+AMD1:2020, Medical devices, Part 1: Application of usability engineering to medical devices
• IEC/TR 62366-2:2016, Medical devices, Part 2: Guidance on the application of usability engineering to medical devices
• ISO 14971:2019, Medical devices, Application of risk management to medical devices
• IEC 62304:2006, Medical device software, Software life cycle processes
• ISO 9241-210:2019, Ergonomics of human-system interaction, Part 210: Human-centred design for interactive systems
• Regulation (EU) 2017/745 on medical devices (MDR)
• Regulation (EU) 2017/746 on in vitro diagnostic medical devices (IVDR)
• FDA Guidance: Applying Human Factors and Usability Engineering to Medical Devices

Related terms

• Usability engineering process
• IEC 62366-2
• Risk management (ISO 14971)
• Usability engineering file
• Summative usability evaluation
• MDR (Medical Device Regulation)
• Critical task
• Human factors engineering (HFE)
• Use-related risk analysis (URRA)

← Back to the wiki overview