---
title: MDR Alarm Management: Where Usability Meets IEC 60601-1-8
description: Alarm design sits at the overlap of EN 62366-1 and EN 60601-1-8. How to tackle alarm fatigue, priorities, and distributed alarms under MDR.
authors: Tibor Zechmeister, Felix Lenhard
category: Usability Under MDR
primary_keyword: MDR alarm management IEC 60601-1-8
canonical_url: https://zechmeister-solutions.com/en/blog/mdr-alarm-management-iec-60601-1-8-usability
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# MDR Alarm Management: Where Usability Meets IEC 60601-1-8

*By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.*

> **Alarm management is a usability problem that happens to live inside an electrical safety standard. EN 60601-1-8 defines priorities, tones, visual conventions, and distributed alarm system requirements for medical electrical equipment, and EN 62366-1:2015+A1:2020 defines the usability engineering process that validates whether real users can actually act on those alarms. Founders who treat alarm design as a compliance checkbox collect alarm fatigue in the field and audit findings in the technical file. Founders who treat it as a shared deliverable between the usability file and the risk file ship safer devices and pass audits faster.**

**By Tibor Zechmeister and Felix Lenhard.**

## TL;DR
- Alarm design sits at the overlap of EN 60601-1-8 (the collateral standard to EN 60601-1:2006+A1+A12+A2+A13:2024) and EN 62366-1:2015+A1:2020, and both must be satisfied for MDR Annex I §5, §14, and §22 to be met.
- Alarm fatigue, where users tune out or silence alarms, is not an operational problem but a design problem rooted in too many alarms, wrong priorities, and weak differentiation between states.
- EN 60601-1-8 defines three priority levels: high, medium, and low, each with its own visual and audible signature. The priorities map to the clinical urgency of the condition the alarm signals.
- Distributed alarm systems, where alarms travel from a bedside device to a central station or a nurse's phone, add a layer of responsibility that the standard addresses explicitly and that notified bodies scrutinize.
- The usability side of alarm design, including discriminability, learnability, and action latency, must be validated through recruited-user summative evaluation under EN 62366-1, not through a design team opinion.
- The exact edition of the alarm collateral standard applicable under MDR is flagged here as ; the substantive design principles below are stable across editions.

## Why alarm fatigue is a regulatory problem, not just an annoyance

Tibor has audited enough ICU-class devices to have formed a strong opinion on alarm fatigue. It is not a nursing problem. It is not a training problem. It is a design problem that shows up at the bedside because the manufacturer treated alarm configuration as a settings screen instead of a hazard analysis deliverable. When a monitor fires forty low-priority alarms an hour, the user stops responding to any of them, and the one high-priority alarm that follows gets silenced with the same reflex. That is foreseeable misuse under MDR Annex I §5.

Felix has watched startup teams dismiss alarm design as a late-stage concern. By the time the firmware is polished, alarm priorities are baked in, audible tones are burned into hardware, and the distributed alarm architecture is already connecting to third-party systems. The startups that treat alarm design as a day-one concern, writing the alarm list into the use specification before writing firmware, avoid the entire class of rework.

MDR Annex I §14 covers protection against risks posed by medical electrical equipment. Annex I §22 adds lay-user considerations for any home-use device with alarms. Annex I §5 is the umbrella under which the usability engineering process lives. All three clauses are in scope.

## What EN 60601-1-8 and EN 62366-1 jointly require

EN 60601-1-8 is the collateral standard to EN 60601-1 that addresses alarm systems in medical electrical equipment. It defines three alarm priority levels: high priority for conditions requiring immediate operator response, medium priority for conditions requiring prompt operator response, and low priority for conditions requiring operator awareness. Each priority level has characteristic audible and visual signatures. High priority alarms use rapid audible pulses and flashing red visual indicators. Medium priority alarms use slower pulses and flashing yellow indicators. Low priority alarms use steady or slow-flashing yellow or cyan indicators with a softer audible signature.

The standard also addresses alarm information signals, alarm inactivation states such as pause and reset, alarm logs, and distributed alarm systems. A distributed alarm system extends the alarm information across multiple devices, and the standard places specific responsibility on the manufacturer to characterize the reliability and latency of that distribution. A bedside alarm that reaches a nurse's phone five minutes late is a different device, in regulatory terms, from one that reaches the phone within five seconds.

Where EN 60601-1-8 defines the skeleton, EN 62366-1:2015+A1:2020 defines the meat. The usability engineering process asks whether a real user, in a real use environment, can distinguish a medium-priority alarm from a high-priority alarm under realistic noise and fatigue conditions. It asks whether the user can silence the alarm safely, whether the user can identify the cause, whether the user can return the device to its normal state without introducing a secondary hazard. None of those questions are answered by the electrical safety standard alone. They are answered by recruited-user summative evaluation with recorded observations and structured outcomes.

The two standards intersect in the hazard-related use scenarios. An auditor looking at the alarm section of a technical file expects to see the alarm priority matrix from the EN 60601-1-8 perspective, the hazard-related use scenarios from the EN 62366-1 perspective, and the risk controls linked to both in the EN ISO 14971:2019+A11:2021 risk file. When any one of these three pieces is missing, the alarm design is incomplete.

## The alarm fatigue chain, step by step

Alarm fatigue follows a predictable sequence that Tibor has seen repeat across device categories. First, a development team adds alarms liberally during testing because each new failure mode feels worth flagging. Second, the team never prunes the list, so devices ship with dozens of alarms that trigger on every marginal variation. Third, the alarms are predominantly low or medium priority because the team is cautious about overclaiming severity. Fourth, users silence the low and medium alarms routinely because nothing bad usually happens. Fifth, the one alarm that signals real clinical urgency arrives in a sea of noise and gets silenced with the same muscle memory.

The design fix for alarm fatigue is to prune the alarm list aggressively, reserve high priority for conditions that genuinely require immediate operator response, make the priority tiers audibly and visually distinct, and validate the entire package with recruited users under conditions that include realistic background distraction. Every one of those fixes lives in the usability engineering process, not in the electrical safety test report.

## Distributed alarm systems: the hidden complexity

Distributed alarm systems deserve their own attention because they hide responsibility transfer inside what looks like a simple feature. A bedside monitor sends an alarm to a central station. The central station forwards the alarm to a specific nurse's mobile device. The mobile device displays the alarm and plays the audible signature. At each step, there is latency, there is a chance of network loss, there is a chance of the receiving device being asleep, silenced, or out of range.

EN 60601-1-8 addresses distributed alarms explicitly. The manufacturer must characterize the distribution reliability and the end-to-end latency, and must design the system such that a primary alarm point is never fully replaced by a downstream one without a safety justification. A bedside alarm cannot rely entirely on the phone having received it. The primary device must continue to alarm until acknowledged locally or until the alarm condition resolves.

The usability consequence is that the user interaction with a distributed alarm is a scenario that must be tested. How does the nurse acknowledge the alarm? Does acknowledgment on the phone silence the bedside device, and if so, is that intended? What happens when two nurses acknowledge the same alarm simultaneously? These scenarios are not edge cases. They are daily occurrences in a busy ward, and a notified body expects to see them covered in the summative evaluation.

## A worked example: a continuous glucose monitor with a phone app alarm

Consider a Class IIb continuous glucose monitor with a sensor on the upper arm and a companion phone app that raises alarms on hypoglycemia and hyperglycemia thresholds. The device is intended for adult type-1 diabetes patients at home.

The alarm design starts from the use specification. The intended user is a lay user, possibly sleeping, possibly with a phone on silent. The hazard-related use scenarios include a nighttime severe hypoglycemia event with the phone on silent mode.

From the alarm collateral side, critical hypoglycemia qualifies as high-priority because it requires immediate operator response. The audible and visual signatures must follow high-priority conventions. The distributed architecture means the phone is the primary alarm point, which the manufacturer must justify.

From the EN 62366-1 side, the summative evaluation must include the nighttime scenario. Recruited users sleep in a simulated environment, the alarm fires, and the manufacturer measures whether the user wakes, how fast, and whether the user takes the correct action. A design that fails to wake users reliably must iterate: a hardware vibration patch on the sensor, a louder escalation pattern, a backup bedside dongle, or a combination.

From the EN ISO 14971 side, the residual risk is assessed after each design fix against the MDR expectation to reduce risk as far as possible.

## The Subtract to Ship playbook for alarm design

Write the alarm list into the use specification, not into the firmware backlog. Every planned alarm condition, its priority, its audible and visual signature, and its intended user action go into the use specification before the firmware is committed.

Prune mercilessly. An alarm that does not require user action should be a status indicator, not an alarm. An alarm that requires user action within an hour is low priority. Within minutes, medium. Immediately, high. Reserve high priority for conditions that genuinely threaten the patient if ignored for more than seconds.

Test alarm discriminability early. A formative evaluation with four participants can reveal whether the medium and high audible signatures are actually distinguishable to untrained ears. That feedback is cheap and saves a firmware rewrite.

Validate the distributed alarm path under realistic conditions. If the alarm travels from device to phone to cloud to phone, test the end-to-end path with network loss, silent mode, and user asleep. The summative evaluation must cover the path, not just the bedside trigger.

Document the alarm matrix in the technical file. The matrix lists every alarm, its priority, its trigger condition, its audible and visual signature, its intended user action, and the hazard-related use scenario that justifies it. A notified body reviewer can read the matrix in fifteen minutes and see whether the design is governed or improvised.

Treat alarm logs as a PMS input. Post-market, the alarm log is a rich source of feedback on which alarms fire too often, which are ignored, and which are silenced. EN ISO 14971 expects that feedback to update probability and severity in the risk file on a regular cadence, not once every two or three years.

## Reality Check

1. Does your technical file contain an alarm matrix that lists every alarm with priority, signature, trigger condition, intended user action, and linked hazard-related use scenario?
2. Have you pruned the alarm list, or did you ship every alarm the team thought was worth adding during development?
3. Are your high, medium, and low priority alarms audibly and visually distinct to an untrained user, and have you proven it in a recruited-user test?
4. If your device uses a distributed alarm system, have you characterized end-to-end latency and reliability, and validated the distributed path in summative evaluation?
5. Does the device continue to alarm locally until acknowledged, or does it rely on a downstream acknowledgment that could be lost?
6. Do you collect post-market alarm log data, and does it feed back into the risk file?
7. Have you avoided the trap of using low priority as a default to hedge on severity?

## Frequently Asked Questions

**Which edition of the alarm collateral standard applies under MDR today?**
The substantive requirements described in this post are stable across the EN 60601-1-8 editions in common use, but the precise harmonized edition listed in the Official Journal evolves. The current edition should be confirmed against the latest Commission implementing decision on harmonized standards, and the status flagged as  before a technical file cites it.

**Is alarm management in scope for software-only medical devices?**
Yes, when the software generates alarms that require user action. The electrical safety collateral does not apply directly, but the usability engineering process under EN 62366-1:2015+A1:2020 and the risk management expectations under EN ISO 14971:2019+A11:2021 do, and the alarm priority conventions from the collateral standard remain the reference users expect.

**What is alarm fatigue, in regulatory terms?**
It is a use error pattern in which the user tunes out or silences alarms due to excessive frequency or weak differentiation. It is treated as foreseeable misuse under EN 62366-1 and must be addressed through design rather than through training.

**Can a device have only one alarm tone?**
It can, but then the priorities must be distinguishable through another channel, and a single-tone design will struggle under the alarm collateral standard. Three distinct tones aligned to the three priorities is the conventional and defensible choice.

**Do notified bodies inspect alarm summative evidence specifically?**
Yes. Tibor confirms that alarm discriminability, alarm action latency, and distributed alarm path validation are regular review points on devices in scope of EN 60601-1-8.

**How many alarms is too many?**
There is no numerical limit. The test is whether the alarm set is justified in the risk file, each alarm has a clear user action, and the summative evaluation shows the user responding correctly under realistic conditions.

## Related reading
- [What Is Usability Engineering for Medical Devices? A Startup Introduction](/blog/usability-engineering-medical-devices-startup) The parent usability primer.
- [IEC 60601-1-8 Alarm Systems](/blog/iec-60601-1-8-alarm-systems) The electrical safety collateral standard deep dive.
- [IEC 60601-1-6 Usability Cross-Reference](/blog/iec-60601-1-6-usability-cross-reference) How the electrical standard hands off to EN 62366-1.
- [Risk Management and Usability Engineering Link](/blog/risk-management-usability-engineering-link) How alarm risk controls flow into the EN ISO 14971 file.
- [Protective Measures: Guards, Alarms, Interlocks](/blog/protective-measures-guards-alarms-interlocks) The risk control hierarchy view of alarms.

## Sources
1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I §5, §14, §22.
2. EN 62366-1:2015+A1:2020, Medical devices Part 1: Application of usability engineering to medical devices.
3. EN 60601-1:2006+A1+A12+A2+A13:2024, Medical electrical equipment Part 1: General requirements for basic safety and essential performance.
4. EN 60601-1-8 (edition status [MDR VERIFY]), Medical electrical equipment Part 1-8: Collateral standard on alarm systems.
5. EN ISO 14971:2019+A11:2021, Medical devices: Application of risk management to medical devices.

---

*This post is part of the [Usability Under MDR](https://zechmeister-solutions.com/en/blog/category/usability) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*