Software as a Medical Device inherits the full weight of EN 62366-1 usability engineering, not a lighter version of it. Screen-based interaction, error messages, and alert handling are use scenarios in the IEC 62366-1 sense. The MDR treats a misread dashboard and a mislabeled physical control as equivalent sources of use-related risk. SaMD teams who skip summative evaluation because the product is "just software" end up in post-market change control.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • EN 62366-1:2015+A1:2020 applies to Software as a Medical Device the same way it applies to hardware devices.
  • MDR Annex I §5 and §22 require that use-related risks be reduced "as far as possible", not "as far as convenient".
  • Screen-based interaction flows, error messages, confirmation dialogs, and alerts are all use scenarios that must be analysed, tested, and documented.
  • Alert fatigue is a use-related hazard and must be treated inside the ISO 14971 risk file, not brushed aside as a UX preference.
  • MDCG 2019-11 Rev.1 pulls many data-driven software products into Class IIa or higher under Rule 11, which makes summative usability evaluation non-optional.
  • SaMD teams that run usability engineering as an afterthought almost always face post-certification change control.

Why SaMD usability is treated like any other device usability

Software as a Medical Device is not a lighter regulatory category. Under MDR Annex VIII Rule 11, most software intended to provide information used for diagnostic or therapeutic decisions lands in Class IIa or higher, and decisions that can cause death or serious deterioration in state of health can reach Class III. The moment the classification leaves Class I, a notified body reviews your technical documentation, and inside that review sits EN 62366-1:2015+A1:2020, the harmonised standard for usability engineering.

Tibor has audited SaMD files where the development team believed usability engineering was a hardware concern and that software only needed "a good UX review". The notified body position is the opposite. EN 62366-1 explicitly covers any user interface, including graphical user interfaces, voice interfaces, and automated interactions. A dashboard is a user interface. An alert banner is a user interface. A confirmation modal is a user interface. Each of them participates in use scenarios that can cause or prevent harm.

Felix has coached founders who learned this the painful way. A product shipped on a 90-day sprint with a screen-based UI that felt intuitive to the founding team was sent back by the notified body for a complete summative evaluation, because the file contained no recruited users, no simulated environment, and no documented observations. The cost of running that evaluation after the fact, under change control, was roughly four times the cost of building it into the original development plan.

What MDR actually says about software usability

Three places in MDR Annex I anchor usability obligations for SaMD.

Annex I §5 requires manufacturers to reduce, as far as possible, risks related to ergonomic features of the device and the environment in which the device is intended to be used, and to consider the technical knowledge, experience, education, training, use environment, and medical and physical conditions of intended users.

Annex I §14.1(d) requires design and manufacture to minimise, as far as possible, risks linked to the possible negative interaction between software and the IT environment within which it operates and interacts.

Annex I §22 applies specifically to devices incorporating electronic programmable systems and to software that is itself a device, and requires that the devices be developed and manufactured taking into account the principles of development life cycle, risk management, verification, and validation, all of which map back to EN 62366-1 for usability and EN 62304:2006+A1:2015 for software lifecycle.

Annex I §23 governs information supplied with the device. The label and instructions for use must be understandable for the intended user. For SaMD, this often means in-product instructional content, tooltips, and context-sensitive help are part of the labelling machinery and must be designed, verified, and validated accordingly.

The presumption of conformity for usability comes from EN 62366-1. The standard defines a nine-step usability engineering process: use specification, user interface specification, hazard-related use scenarios, user interface evaluation plan, user interface design and implementation, formative evaluation, summative evaluation, user interface of unknown provenance, and usability engineering file. SaMD teams cannot skip steps. Each step must produce a documented artefact that survives a notified body review.

A worked example: a clinician-facing decision-support dashboard

Consider a web-based clinical decision-support tool that surfaces laboratory trends and flags values outside expected ranges. Intended users: hospital clinicians. Intended environment: hospital wards, on a shared workstation, sometimes under time pressure. Classification under MDR Annex VIII Rule 11 with MDCG 2019-11 Rev.1: Class IIa, because the tool informs therapeutic decisions and the impact of incorrect information is not negligible.

A competent EN 62366-1 process for this product looks like this.

Use specification. Not a single sentence. Every real-world scenario decomposed: login in a crowded ward, interpreting a trend on a small screen, acknowledging an alert while holding a phone, handing the workstation to a colleague mid-task, using the tool during a night shift with low ambient light. Tibor's rule: granular procedures make hazards visible; compressed procedures hide them.

User interface specification. Every screen, every dialog, every alert condition, every keyboard shortcut. Includes the content of alert messages, not just their layout.

Hazard-related use scenarios. Not "user clicks the wrong button" at the top level. Specific chains: user acknowledges a critical alert thinking it is a routine one because both use the same visual treatment; user misreads a trend because the chart axis auto-scaled; user dismisses a confirmation modal because it looks identical to ten unrelated modals they have already dismissed today. Alert fatigue is a named hazard category in the risk file, not a design aesthetic.

Formative evaluation. Iterative testing with clinicians during development. Small samples, early prototypes. The goal is learning, not evidence.

Summative evaluation. Recruited clinicians representative of the intended user population, in a simulated ward environment, performing the critical tasks with no coaching. Recorded observations, documented outcomes, pass or fail criteria tied back to the hazard-related use scenarios.

Usability engineering file. Every artefact above, cross-referenced to the ISO 14971 risk management file and the EN 62304 software requirements.

The file is not a separate binder. In Tibor's audit experience, the files that pass cleanest are the ones where the usability artefacts are integrated with the software requirements and the risk file, so that when an auditor pulls a requirement, a risk, or a test report, the chain is visible.

The Subtract to Ship playbook for SaMD usability

Felix's Subtract to Ship method for SaMD usability has one governing principle: build the usability engineering process into the software lifecycle from the first sprint, and subtract every screen, alert, and interaction that is not load-bearing for the intended purpose.

Step 1. Lock the intended purpose and the use specification before the first production-quality screen is built. If the product claims to inform therapeutic decisions, the use specification must include the decision points, the users who make them, and the environments in which they are made.

Step 2. Decompose use scenarios procedure by procedure. Tibor's divide-and-conquer approach from hardware applies directly: login, routine task, edge case, error recovery, handover, offline behaviour, update behaviour.

Step 3. Name the alert budget. Alert fatigue is a hazard. Every alert that ships must earn its place. An alert that fires twenty times a shift for a condition that is critical three times a year is a hazard factory. Reduce alerts until every remaining alert carries information the user needs to act on.

Step 4. Write error messages as clinical content, not developer content. "Network error" is not a use-safe message when the user has no fallback. The message must tell the user what happened, what to do, and what the system will not do. EN 62366-1 treats error messages as user interface elements subject to the same evaluation as any other.

Step 5. Run formative early, run summative before freeze. Formative evaluation with five clinicians in week six costs almost nothing and changes the architecture. Summative evaluation on frozen software with recruited users is the gate. Do not confuse the two.

Step 6. Keep the usability engineering file alive after launch. Post-market surveillance feedback on usability must flow back into the risk file and the usability engineering file. A SaMD team that treats usability as a one-shot activity will find itself in change control when the first real-world use error surfaces.

Reality Check

  1. Does your use specification list every real-world procedure for the product, or does it describe "the user uses the software"?
  2. Are alerts listed in the risk file with severity and probability, or are they treated as a UX decision only?
  3. Can you point to recruited users in a simulated environment who tried to complete the critical tasks with no coaching?
  4. Do your error messages tell the user what to do, or do they show a code and a stack?
  5. Is your usability engineering file cross-referenced to the ISO 14971 risk file and the EN 62304 software requirements?
  6. Would a notified body auditor find summative evaluation evidence on the frozen release, not on an earlier prototype?
  7. Have you decomposed use scenarios far enough that alert fatigue and modal-dismissal habits are explicitly analysed as hazards?

Frequently Asked Questions

Does EN 62366-1 really apply to pure software products? Yes. EN 62366-1:2015+A1:2020 covers any user interface on a medical device, including purely software user interfaces. MDR Annex I §5 and §22 do not distinguish between hardware and software when setting usability obligations.

Can a SaMD team skip summative evaluation if formative evaluation went well? No. Formative and summative serve different purposes. Formative is for learning during development. Summative is the final validation with recruited users and documented outcomes. Notified bodies will look for summative evidence on the frozen release.

Is alert fatigue really a regulatory issue or just a UX concern? It is a regulatory issue. Alert fatigue degrades the user's ability to respond to critical information and therefore contributes to use-related hazards that must be analysed under EN 62366-1 and ISO 14971.

How does MDCG 2019-11 Rev.1 affect our usability obligations? MDCG 2019-11 Rev.1 drives most diagnostic and therapeutic decision-support software into Class IIa or higher under Rule 11. The higher classification triggers notified body review of the technical documentation, which includes the usability engineering file.

Our engineers find the product intuitive. Is that enough for summative evaluation? No. Engineers are not the intended user population. EN 62366-1 requires evaluation with recruited users representative of the intended user profile. Testing with your own team is one of Tibor's most-cited audit findings.

Do tooltips and in-product help count as instructions for use? Under MDR Annex I §23, information supplied with the device includes labelling and instructions for use. For SaMD, in-product instructional content that supports safe use is part of that obligation and must be designed and validated accordingly.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I §5, §14.1(d), §17, §22, §23. Annex VIII Rule 11.
  2. EN 62366-1:2015+A1:2020, Medical devices. Part 1: Application of usability engineering to medical devices.
  3. EN 62304:2006+A1:2015, Medical device software. Software life cycle processes.
  4. EN ISO 14971:2019+A11:2021, Medical devices. Application of risk management to medical devices.
  5. MDCG 2019-11 Rev.1 (June 2025), Guidance on qualification and classification of software in Regulation (EU) 2017/745 MDR and Regulation (EU) 2017/746 IVDR.