Usability Engineering for SaMD: IEC 62366 and Annex I Requirements

Why usability engineering trips up SaMD teams

Usability engineering is one of those requirements that SaMD manufacturers often think they have handled — and then discover during Notified Body review that they haven't. The gap is usually not that teams ignored usability. It's that they did informal, ad-hoc testing, documented it poorly, and couldn't show the structured process that IEC 62366-1 and GSPR Chapter I require.

GSPR Section 5 is the Annex I provision: devices must be designed and manufactured in a way that they are suitable for their intended purpose, taking into account the generally acknowledged state of the art. For software with a user interface, that means a documented usability engineering process — and IEC 62366-1 is the standard that defines what that process looks like.

The core structure of IEC 62366-1

IEC 62366-1 frames usability engineering as a lifecycle process, not a one-time test. The key activities run in sequence:

Intended user population and use environment — who uses the software, in what context, with what level of training and familiarity? A clinical decision support tool used by intensive care clinicians under time pressure is a different usability problem than an administrative tool used by trained scheduling staff at a desktop. Define the user population and the use context before you design anything.

Intended user interface and user interaction — document the user interface elements and user tasks. For software, this means the specific screens, workflows, and decision points where users interact with the system. This feeds into your user task analysis.

User task analysis — break down what users actually do when they operate the software. Which tasks are safety-critical? Where does incorrect operation create patient safety risk? This analysis drives what you test in summative evaluation.

Formative evaluation — iterative usability testing during development. Not a final pass/fail test — a process of finding and fixing usability problems before they become safety issues. Document what you tested, what you found, and what you changed. This is often poorly documented; the records from formative rounds are as important as the summative results.

Summative evaluation — the final usability test performed on the finished (or near-final) software with a representative sample of intended users completing realistic tasks in a representative context. This is what ends up in your technical file.

What the summative evaluation has to show

The summative evaluation is where many teams underinvest. A few things Notified Bodies look for:

Representative participants — not colleagues, not volunteers who happen to be in the building. People who match the intended user profile: the right clinical role, right level of experience, right familiarity with similar software. If your intended users are radiologists, your summative evaluation participants should be radiologists.

Realistic tasks — scenario-based tasks that reflect actual clinical use, not feature demonstrations. "Enter a patient and run the analysis" is not a task scenario. A realistic scenario gives participants enough clinical context to make the decisions they would actually face.

Safety-critical use errors identified and addressed — the summative evaluation must specifically test the tasks identified as safety-critical in your user task analysis. If participants make errors on those tasks, you have a problem to address before the evaluation is complete.

The right sample size — IEC 62366-1 gives guidance but doesn't mandate a specific number. In practice, most Notified Bodies expect at least 15 participants for a summative evaluation of a Class IIa or above device. Smaller sample sizes require explicit justification.

Connecting usability to risk management

This is the integration that matters most and that the GSPR requires: usability engineering and ISO 14971 risk management must be connected, not run as parallel silos. Use errors and misuse are hazardous situations under ISO 14971. Your user task analysis should feed into your hazard identification. Risk controls that depend on the user doing something correctly need to be verified through usability evaluation.

If your risk management file says "user training mitigates this risk" — that claim needs evidence from your usability evaluation that trained users can in fact perform the relevant task reliably. "Training" is only a risk control if you can show it works.

What changes for software-only devices

IEC 62366-1 was written to apply to all medical devices, and a lot of its examples assume hardware. For software, the key differences in practice:

The use environment is complex and often not fully controlled — hospital Wi-Fi, multiple screen sizes, integration with other systems. Your use environment analysis needs to account for realistic deployment conditions, not an ideal setup.

Iterative development creates version management challenges. Your summative evaluation must be on a version that is representative of what will be released. If significant UI changes are made after summative evaluation, you may need to evaluate again.

Mobile applications specifically create challenges around screen size, notification interruptions, and input methods. If your SaMD is or includes a mobile app, your usability program needs to address these explicitly.

Where to start if you haven't done this yet

If you're approaching this for the first time, the practical starting point is the user task analysis — it forces clarity about what users actually do and which tasks are safety-critical. From there, the formative/summative structure follows. IEC TR 62366-2 (the technical report companion to the standard) contains useful guidance on how to apply the standard in practice, with examples that are more practically oriented than the normative text.