What does IEC 62366-1 ask of your software team?
Gideon Awolesi ·
If you're building software for a medical device, or software that is a medical device in its own right, IEC 62366-1 is the usability engineering standard notified bodies and the FDA expect you to follow. A lot of teams write the usability engineering file once the design is already finished. That's when the gaps show up: critical tasks that were never tested, and hazard-related use scenarios that don't match the risk analysis.
01What the standard is about
IEC 62366-1 is about use errors: the things people do with a device that the manufacturer didn't intend, and that can lead to harm. It asks you to run a usability engineering process alongside your risk management under ISO 14971, and to keep the evidence in a usability engineering file.
What a lot of people don't understand is that the standard doesn't tell you what your interface should look like. It asks you to show, with evidence, that people can use it safely.
02What it asks your team to produce
For a software team, the process comes down to these outputs, and each one builds on the one before it:
- A use specification: who uses the product, where, and for what.
- The user interface characteristics related to safety, and the use errors that could happen with them.
- The known or foreseeable hazards and hazardous situations.
- Hazard-related use scenarios, and the ones you'll select for summative evaluation.
- A user interface specification and a user interface evaluation plan.
- Formative evaluations while you design, and a summative evaluation at the end.
- The usability engineering file, which holds all of the above.
Formative evaluation is prototype testing with people from your user group. Summative evaluation is the test that shows the finished interface can be used safely for the scenarios you selected.
03What it means for designers and developers day to day
The user interface specification is a design artefact. It should come out of the same work as your Figma files, and it should change when the design changes. If the design and the specification drift apart, the file stops describing the product you're actually shipping.
Every design decision that affects a hazard-related task needs a reason you can trace back to the risk analysis. That's much easier to write down while you're making the decision than to reconstruct months later for a notified body.
04Adding a feature to a device that's already validated
When you add a new parameter or an AI feature to a device, you add new failure modes, even if a lot of the workflow stays the same. In a medical device project we worked on for Philips, a new clinical parameter was going onto its bedside monitors. Before any screen was final, we turned the clinical and engineering requirements into 14+ use scenarios, five safety decisions, and uFMEA inputs, so the clinical, risk, and engineering teams could review how the parameter should behave.
We separated the new tasks from the ones that were already validated, so the testing focused on where the new risk was. This way, the testing covers the tasks the change actually affects, and the parts of the device that were already validated don't have to be tested again.
05If you're about to submit
Our Usability Review checks your usability engineering file against IEC 62366-1 and the FDA human-factors guidance, clause by clause, and gives you a ranked list of what to fix ahead of your submission. Design and conformity decisions, and the submission itself, stay with you as the manufacturer.