Usability Engineering for SaMD (IEC 62366)
For Software as a Medical Device, a confusing screen is not a UX debt item — it is a hazard. IEC 62366 frames usability engineering as a systematic way to find use errors, reduce them through design, and produce evidence that intended users can operate the software safely. Teams that treat usability as visual polish discover the gap when a formative study surfaces a predictable mis-tap that would alter a dose or a triage priority.
Use error as hazard, not user blame
Regulators and standards bodies converge on a simple idea: people will misunderstand, rush, interrupt, and work in poor lighting. The device must remain safe under those conditions. The FDA’s guidance on applying human factors and usability engineering to medical devices emphasises identifying use-related hazards and designing the user interface to minimise them — then validating that residual risk is acceptable.
IEC 62366 operationalises a similar lifecycle for medical devices, including software: specify use, analyse hazards related to use, design and evaluate iteratively, and document the file. For SaMD, the “interface” is often almost the entire device.
Rule: If a trained user can still make a critical error that the UI invites, the hazard belongs to the design — document it, mitigate it, or justify residual risk explicitly.
Know the users, uses, and environments
SaMD is frequently used by mixed populations: specialists, generalists, nurses, patients at home, or lay caregivers. Each group brings different mental models and interrupt patterns. A hospital workstation with a badge reader is not the same environment as a phone on a night shift or a tablet in an ambulance.
Write intended-use statements that name users and environments without marketing fog. Then derive critical tasks: the steps where failure can cause serious harm. Those tasks drive formative evaluation priorities and summative validation protocols. Everything else can be improved later; critical tasks cannot be left to anecdote.
Formative versus summative — both are required in practice
Formative studies happen early and often. They are allowed to find problems. Small samples, think-aloud sessions, and prototype walkthroughs are tools to reshape information hierarchy, confirmation patterns, and wording before code hardens.
Summative (validation) studies happen on the near-final UI with representative users performing critical tasks without help. The goal is evidence that residual use-related risk is acceptable. Coaching during summative tasks invalidates the evidence.
Skipping formative work and jumping to a single late summative study is a common failure: you discover fundamental layout issues when changing them is most expensive — and when release pressure encourages rationalising away failed tasks.
What IMDRF definitions imply for software teams
The IMDRF SaMD key definitions remind manufacturers that SaMD is software intended for medical purposes without being part of a hardware medical device. That independence puts extraordinary weight on the UI and on the clarity of outputs. There is no physical knob to fall back on when the screen misleads.
For teams running SaMD and AIaMD development, usability engineering must cover model outputs as interface: confidence displays, forced acknowledgements, differential diagnosis lists, and override paths. An opaque score with no explanation is a usability and clinical-risk problem at once.
Hazard analysis that connects to the UI
Link use errors to harms in the risk file with enough specificity to design mitigations:
- Wrong patient selected → wrong record edit or wrong advice shown.
- Unit confusion (mg vs mcg) → dosing error.
- Alert dismissed without reading → missed contraindication.
- Mode confusion between training and live data → false clinical action.
- Accessibility failures (contrast, target size) → mis-reads under fatigue.
Mitigations are design controls first: distinctive patient banners, constrained inputs, plain-language alerts, undo windows, and safe defaults. Training and IFU text are supporting controls, not the primary defence for foreseeable errors.
Integrating usability into software delivery
Agile teams fear that IEC 62366 means waterfall. It does not — but it does mean you cannot silently reshape critical tasks every sprint without evaluation. Practical integration patterns:
- Tag stories that touch critical tasks; require formative review before release candidates.
- Keep a living usability engineering file alongside the risk management file.
- Freeze UI for critical tasks before summative validation; park non-critical polish afterwards.
- Re-evaluate when a “small” UI change alters task flow — the same discipline you apply to significant software changes under MDR.
Custom hospital platforms that embed SaMD modules inherit the same obligations for those modules even when the surrounding healthcare software development estate is not itself a medical device. Boundary clarity in intended use prevents the organisation from pretending the regulated UI is “just another screen.”
Evidence reviewers expect to see
A credible usability package typically includes use specification, known use-error analysis, formative summaries with design changes traced to findings, summative protocol and results for critical tasks, residual risk discussion, and how labeling/training address remaining issues. Videos and task success rates help; unexplained statistics do not.
Rule: Trace every critical-task failure in summative testing to either a design change, a residual-risk acceptance with clinical rationale, or a protocol defect you will correct and retest.
AI-enabled SaMD and the explainability trap
AIaMD interfaces often surface ranked suggestions, heatmaps, or risk scores. Usability engineering must ask whether clinicians understand what the output is — and is not. Over-trust and under-trust are both use-related hazards. Formative work should probe whether users can state the intended use in their own words after a short exposure, and whether they know how to proceed when the model abstains or returns low confidence.
Forced acknowledgements help only when they interrupt at the right moment and use language that matches clinical workflow. A modal every thirty seconds creates alert fatigue; a silent score creates automation bias. Summative protocols should include scenarios where the model is wrong in a realistic way, not only happy-path correctness.
International users and localisation
SaMD sold across markets inherits language, unit, and date-format hazards. Localisation is a usability control: mistranslated alerts and ambiguous decimal separators have caused real dosing errors in other device classes. Plan formative evaluation in each major language and region of use, or document why a narrower claim is justified. Screenshots in a single language do not defend a global IFU.
Accessibility requirements — contrast, keyboard paths, assistive technology — belong in the same hazard analysis when the intended users include people with visual or motor limitations, including clinicians with situational impairments on night shifts.
Closing
IEC 62366 usability engineering turns SaMD interfaces from aesthetic preference into hazard control. Treat use errors as design problems, study them early, validate them honestly, and keep the file aligned with risk management. That discipline protects patients and shortens difficult conversations with regulators.
If you are preparing formative plans or stitching usability evidence into a SaMD technical file, Yoctobe can review the critical-task list and study design with your clinical and engineering leads before the next validation round.
