Medical Usability and Regulation: Finding Your Way Through the Regulatory Landscape of Medical Device Development

It usually goes wrong in this order: design first, test second, document afterwards. The most expensive route of all. This page sorts out which requirement applies when, and how the MDR, risk management and usability engineering connect. For development leads, product managers and quality assurance. Written from design practice, not from an auditor’s chair.

Three sets of rules, one stack. The MDR demands the outcome, ISO 14971 supplies the risk view, IEC 62366-1 the route there. See that early and you save yourself the loops every second project runs: evaluation scheduled too late, design decision justified after the fact, use-related risk found only in validation. Those loops cost weeks. Sometimes the launch date.

The MDR sets the legal framework

Regulation (EU) 2017/745 on medical devices sets out general safety and performance requirements. Annex I is the part that matters most for design: risks arising from use must be reduced as far as possible, among other things through ergonomic design and by taking into account the knowledge, experience and use environment of the intended users. The MDR does not prescribe a method. It requires a result and documented evidence that the result was achieved systematically.

ISO 14971 provides the risk perspective

ISO 14971 describes risk management across the entire product lifecycle: identifying hazards, evaluating risks, defining measures, assessing residual risk and continuing to monitor the device in the field. Use-related risks are part of this. Risk management therefore supplies the inputs for user interface design and, in turn, takes its outputs back in.

IEC 62366-1 provides the process

IEC 62366-1 describes how knowledge about users and use context becomes a safely operable user interface, and how that path is documented. It is a process standard: it does not prescribe a design, but a traceable approach that leads to one. Where it sits among the other rules is what this overview covers. How the process runs in an actual project, which documents it produces and where projects typically lose time is covered in detail in our practical guide to IEC 62366-1.

Human factors is the international perspective

For the US market, the FDA human factors guidance applies as well. It follows the same underlying logic but sets its own emphases, for instance on validation testing and its scope. If you are addressing both markets, plan evaluations from the outset so they satisfy both sets of requirements. Extending a summative evaluation to a second market after the fact is rarely possible.

The most common misconception: that usability engineering is a test at the end. In practice it is a sequence of decisions that starts in the first week of concept work. Postponing it does not reduce the effort, it only moves the point at which the effort becomes expensive.

Concept phase

This is where the use specification and use context take shape: who operates the device, with what qualification, in what environment, under what pressure. Identification of hazard-related use scenarios begins in parallel. Both underpin everything that follows and cannot be reconstructed later, only asserted after the fact.

Design phase

Now the user interface specification becomes concrete. Interaction logic, labelling, hierarchy, ergonomics. Formative evaluations run alongside, and they are not a checkpoint but a tool: they expose what nobody sees at a desk. A change after the third formative round is an iteration. The same change after the summative evaluation is a re-validation.

Verification and validation

The summative evaluation demonstrates that critical tasks are performed safely under realistic conditions. It requires a largely frozen design. Findings at this point that force a design change cost time in the most critical stretch of the project.

After market launch

Findings from post-market surveillance feed back into risk management and the usability engineering file. For subsequent product generations this is the most valuable data a manufacturer has.

In many projects two strands run in parallel: one for design, one for regulatory affairs. One looks for the best solution, the other provides assurance. Run separately, they create friction, because every design decision has to be justified later and every regulatory requirement arrives as a constraint. In the end one team defends what the other designed.

We work the other way round. Analysing the use context is not a deliverable for the documentation but the starting point of the design. Hazard-related use scenarios become requirements for form, layout and interaction. Formative evaluations become design decisions that can be evidenced. The result is a product that is easy to operate not despite the standards but because the process led there.

This way of working comes from practice: from more than 300 series products, a substantial share of them in medical and dental technology, from the surgical light and the endodontic motor to a diagnostic device for structurally weak regions.

Depending on where your project stands, we join at different points: in the concept phase with use context analysis and the interaction concept, in the design phase with industrial design and the interface, and in the assurance phase by planning and supporting evaluations. Through to production readiness this remains a single chain of decisions. What emerges is both: a product that holds up in clinical routine and documentation that holds up too.