Two Alarms at Once: Document the Device State and Acknowledgement Sequence

The Direct Answer: Record the Interaction Step by Step

When a second alarm condition becomes active before the first is resolved, a device team needs more than a note saying the alarm sounded and was acknowledged. It needs to reconstruct which conditions were active, what the user could see and hear, what the operator's control actually did, and what the device was doing at each step. For many devices with alarm systems, overlapping conditions are a foreseeable use scenario rather than an exotic edge case, so the evidence deserves its own structured record.

Short answer: Use a sequence record that keeps each underlying alarm condition, its displayed and audible indication, the operator's exact action and its scope, and the device's operating state in separate fields. Compare the sequence with requirements defined for the specific product, software version, configuration and use environment. An acknowledgement or a quiet screen does not by itself establish that every underlying condition has ended. Evaluate both event orders and overlapping conditions where the risk analysis makes them relevant. The proposed record is an editorial verification aid, not an FDA-prescribed test, universal priority algorithm or clinical response protocol.

To make that record reviewable, keep apart four layers that a one-line test note tends to collapse into one:

• Underlying alarm condition: The physical, physiological or software-detected state that triggered the alarm (for example, an upstream line occlusion, air in line or low battery). The condition exists independently of whether the device is currently sounding or displaying anything about it.

• Indication presentation: What the device presents to the user: the displayed alarm message, any pending or secondary list, status lights, and audible or tactile signals, each as defined by the product's own alarm-system requirements.

• Operator action and scope: The control the user operates, such as an audio pause, acknowledge, reset or override control. The record must capture the documented scope of that action: only the displayed alarm, all active alarms, technical alarms, the audible channel alone, or future signal generation.

• Device operating state: What the device is actually doing: delivering therapy, running at a reduced rate, holding, clamped or in a safe state. This can change independently of what the display and speaker show.

Define the Product and Expected Behavior Before the Test

Multi-alarm sequences cannot be verified against expectations that were never written down. Before any bench run, the team should specify the exact product configuration, software build, operating mode and the functional requirements that govern concurrent alarm handling, so each ledger row has something to be compared against.

Arbitration behavior can depend on build and configuration. Hypothetically, the same infusion device might rank or handle alarms differently in a standalone mode than when docked and networked. The protocol should therefore record the software version, hardware revision, accessories, operating mode and use environment under evaluation, and link each scenario back to design inputs, as described in our design verification test protocol guide.

The requirements must also define what every alarm-related control does. Control names and behaviors vary by manufacturer, so define each control in the product's own terms. The categories below are common reference points, not universal definitions:

• Audio pause or audio silence: Temporarily suppresses audible signals for a duration the product defines (the historical Prismaflex manual discussed below, for example, describes a MUTE softkey that silences the audible alarm for 2 minutes). Whether visual indications continue, and whether a new condition breaks through the pause, must be specified rather than assumed.

• Acknowledgement: Confirms operator awareness. Depending on the implementation, it may silence audio, switch off alarm lamps, change a flashing indication to steady or add an acknowledged marker, without implying that the triggering condition has resolved.

• Reset or clearing: Removes a latched or retained indication. When a reset is permitted, for example only after the condition has ended, is a product requirement that should be stated explicitly and verified.

• Override: Some products allow an alarm to be overridden for a defined period so the operator can complete a corrective step. Record whether the alarm is still treated as active, which indications change and which device actions resume.

Each of these behaviors should trace to a design requirement and, where relevant, to a risk control and to the use-related risk analysis that identifies critical tasks; our traceability matrix guide covers that lineage. Keep two evidence questions apart: design verification asks whether the implemented behavior matches the specification, while usability engineering asks whether intended users can perceive and correctly respond to those states in realistic use. See design verification vs. validation and our IEC 62366 usability engineering guide for the broader methods.

For alarm-system design, FDA's human factors premarket information page lists IEC 60601-1-8 (general requirements, tests and guidance for alarm systems in medical electrical equipment and medical electrical systems) as a design standard for alarm systems, and points readers to the FDA Recognized Consensus Standards database for the current recognized edition and extent of recognition. Check applicability and recognition status for your own device separately; publication of a standard is not the same as its recognition or legal adoption. This article does not reproduce or interpret clauses of that standard, and no standard replaces the product-specific state-transition requirements your ledger is tested against.

Why a Quiet or Single-Message Screen Is Incomplete Evidence

A common weak spot in verification reports is a multi-alarm test summarized as “Result: Pass. Alarm acknowledged, screen quiet.” A single snapshot of the main display, or the absence of sound, leaves a traceability gap: a quiet device or a single displayed message can hide conditions that are still active.

Two manufacturer documents, one historical and one recent, show why. Each is bounded to its own model, release and configuration, and they are cited only to illustrate the evidence problem, not as interchangeable designs or current market-status statements.

Example 1: One Alarm Screen With a Pending List Behind It

The historical Prismaflex Operator's Manual for Program Version 7.xx (G5039912, Chapter 9), covering an extracorporeal blood purification control unit, states that all alarms are prioritized: when multiple problems exist, only the highest-priority alarm screen is displayed, and clearing that alarm causes the next-highest alarm screen to appear. Whenever an alarm occurs, its name is also stored in a pending (active) alarms list, which the operator can view with the EXAMINE ALARMS softkey until the alarm is cleared.

The same chapter describes several layers separately. The MUTE softkey temporarily silences the audible alarm. A Warning alarm puts the control unit into a safe state by stopping all pumps and closing the return line clamp. Some alarms can be overridden for a short period, during which the Warning screen leaves the display and the pumps restart, yet the manual states that overridden alarms are considered active alarms. A verification record built only from images of the main alarm screen would miss conditions sitting in the pending list. This is a version-bounded illustration of why the ledger needs separate fields, not a description of current products, a clinical instruction or a generic priority rule.

Example 2: Broad Acknowledgement Scope and Persistent Messages

The Philips Telemetry Monitor 5500 Instructions for Use, Release 4.0 (document 4535 649 28311, first edition 2025), illustrates a different acknowledgement scope. The monitor generates physiological alarms and technical alarms (INOPs), and the IFU sets out its own rules for which alarm has the highest priority. Touching the acknowledge alarm button acknowledges all active physiological alarms and INOPs and switches off the audible alarm indicators and alarm lamps for active alarms.

Acknowledgement does not make every message disappear. If the triggering condition is still present after acknowledgement, the alarm message stays on the screen with an acknowledged icon beside it, except for alarms from certain intermittent measurements, whose messages disappear when acknowledged. The IFU also notes that red alarms are latched at a connected PIC iX system until acknowledged. One operator action therefore changed audible and lamp indications for several alarms at once while the conditions themselves could persist, and configuration, connection state and latching all affect what the user sees.

Neither example should be merged into a single algorithm. Together they show only why verification documentation cannot treat acknowledgement as a simple yes/no flag: an action may affect one alarm or all of them, and a quiet device might mean an audio pause, an acknowledged but persisting condition, a lower-priority alarm waiting behind the displayed one, or genuine resolution. A useful record captures each of these dimensions separately.

A Synthetic Alarm Order and Acknowledgement Record

To resolve these ambiguities, record the interaction as a chronological ledger. Below is an original synthetic record for a fictional two-channel infusion system (“Example Pump EX-2”, build demo-1.0). Every expected entry stands in for what that fictional product's own requirements would say, and the requirement IDs are placeholders. In the worked sequence, Condition A (an upstream occlusion on channel 1) occurs first, and Condition B (a downstream occlusion on channel 2) becomes active while A persists. The fictional requirements rank B above A; that ranking is part of the example, not a general rule.

Start with a case header that fixes the context every row depends on:

The table below details the chronological progression from baseline (E0) through condition injection, operator intervention, sequential fault clearance, and system restoration (E5):

The value of the ledger lies in the separation between columns. At E3, the operator's acknowledge action changes the expected audible indication, but the active set remains {A, B} and the operating state remains a protective hold. A tester recording only sound or the main message would report that the device was quiet, and could miss a defect such as the pending entry for A disappearing prematurely or a channel restarting while its condition persisted. The final column stays not executed on every row: the table shows what evidence to collect, not evidence that anyone collected.

A practical review test: if a row is supported only by “alarm acknowledged”, can a reviewer still tell which conditions persisted and what the device was doing? If not, the gap is a missing requirement or missing evidence, and it should be closed as such rather than filled with an assumed rule.

The diagram below shows the same synthetic sequence as four parallel tracks, so it is easy to see where an operator action touches indications and state without ending any condition:

flowchart TD
  subgraph Conditions["Underlying condition track"]
    C0["E0: active set { }"] --> C1["E1: A introduced, active { A }"]
    C1 --> C2["E2: B introduced, active { A, B }"]
    C2 --> C3["E3: both persist, active { A, B }"]
    C3 --> C4["E4: A removed, active { B }"]
    C4 --> C5["E5: B removed, active { }"]
  end

  subgraph Indications["Indication track"]
    I0["E0: no alarm indication"] --> I1["E1: A indicated"]
    I1 --> I2["E2: B primary, A pending"]
    I2 --> I3["E3: A and B acknowledged, audio paused"]
    I3 --> I4["E4: B primary, A resolved"]
    I4 --> I5["E5: latched indication or resume prompt"]
  end

  subgraph OperatorAction["Operator action track"]
    A0["E0: none"] --> A1["E1: none"]
    A1 --> A2["E2: none"]
    A2 --> A3["E3: acknowledge, scope all active alarms"]
    A3 --> A4["E4: none, harness removes A"]
    A4 --> A5["E5: restart confirmation as specified"]
  end

  subgraph DeviceState["Operating state track"]
    S0["E0: both channels delivering"] --> S1["E1: channel 1 paused"]
    S1 --> S2["E2: protective hold"]
    S2 --> S3["E3: hold maintained"]
    S3 --> S4["E4: hold maintained for channel 2"]
    S4 --> S5["E5: hold until operator confirms"]
  end

  C1 -.-> I1
  C2 -.-> I2
  A3 ==> I3
  A3 -.-> S3
  C4 -.-> I4
  C5 -.-> I5

Reverse the Order and Challenge the Acknowledgement Boundary

Testing only one arrival order leaves an obvious question unanswered. An arbitration design can behave differently when a higher-ranked condition arrives second rather than first; a lower-ranked condition arriving during a higher-ranked alarm could be queued correctly, displayed incorrectly or lost. Only a reverse-order case can show which.

The table below lists candidate cases for the same ledger. Choose among them based on product-specific risk and implementation. It is not a mandated suite or exhaustive coverage, and intervals such as t1 or the observation window are placeholders to be set from your own requirements:

Each case answers one evidence question, and which ones apply depends on the hazard analysis and the implementation. Case 4 shows why: if a user pauses audio for one condition and a more serious one arises during the pause, the requirements must say whether the new condition breaks through, and the record must show what actually happened. That is not a universal breakthrough rule; it identifies a behavior that should be specified and verified rather than assumed. Recording the selected cases and the rationale for omitting others makes the coverage decision itself reviewable.

Check What Intended Users Can Perceive and Interpret

A device can execute every state transition exactly as specified on the bench and still contribute to use errors if users cannot perceive, understand or prioritize concurrent indications. Design verification establishes that the equipment meets its specifications; human factors validation asks whether intended users can use the device safely and effectively under realistic conditions.

FDA's final guidance Applying Human Factors and Usability Engineering to Medical Devices (issued August 3, 2026; originally issued February 3, 2016) frames this distinction. Section 6.1 ties critical-task identification to use-related risk, and the guidance defines a critical task as one that, if performed incorrectly or not performed at all, would or could cause serious harm to the patient or user. Section 8.1 recommends that environmental factors that might affect users' interactions with the user interface be incorporated into the simulated-use environment, and lists multiple alarm conditions among its examples. These are nonbinding recommendations to be applied to the specific device, not a requirement for this article's ledger.

In a multi-alarm scenario, candidate critical tasks, to be confirmed by your own use-related risk analysis, may include:

• Alarm discrimination: Distinguishing a higher-priority alarm from lower-priority or technical alarms when several signals occur together or in quick succession.

• Pending-alarm discovery: Recognizing that another active condition exists in a pending list or status area, rather than assuming the displayed message is the only problem.

• Understanding action scope: Knowing what a silence or acknowledge action accomplished, for example that it changed the audible signal but did not clear the underlying occlusion or resume delivery.

• Safe resumption: Confirming that the necessary corrective actions are complete before resuming therapy.

Sections 8.1.5 and 8.1.6 describe collecting observational, knowledge-task and interview data and analyzing validation results qualitatively to find the root causes of use errors, close calls and use difficulties. That is a different exercise from bench verification against requirement-level acceptance criteria. If simulated-use participants repeatedly miss a pending occlusion entry because a displayed battery alarm holds their attention, that finding points to a use-related risk even if the firmware passed every bench case. Keep the engineering ledger and any participant-study results in separate records; a scripted sequence cannot answer the human-factors question. For planning the study itself, see our human factors testing guide.

Home-Use Considerations

For devices intended for home use, FDA's final guidance Design Considerations for Devices Intended for Home Use (issued November 24, 2014; updated August 8, 2016), in its section on alarm systems, notes that alarm systems are of particular concern because noise and other distractions inside and outside the home can interfere with users' awareness of an alarm signal, and that users may have hearing impairments, including the inability to hear specific frequencies. It recommends designing high- and medium-priority alarm signals to be perceived in environments typically found in the home.

The same section addresses connected alarm systems: where an alarm system incorporates wired or wireless connections to other locations, the entire device system should be designed and tested to mitigate risks from loss or degradation of those connections. For a home-use product with distributed alarms, the sequence record may therefore need to note what the remote location received at each event, not only what the device itself presented. These considerations apply where the intended use includes the home; they do not turn hospital examples such as those above into home-use devices.

Close Gaps With Evidence and Keep the Scope Visible

When multi-alarm evidence goes into a design history file or supports a premarket submission, reviewers will look for traceable support rather than assumptions. Five record defects are worth checking before the file is closed.

The table lists each defect, why it matters and example options for closing the gap. Choose what your product and risk analysis require, and state explicitly when a capability such as native event logging does not exist rather than implying that every device must provide it:

The practical takeaway is narrow but useful. Keep conditions, indications, operator actions and operating state in separate fields; tie every expected entry to a product requirement; challenge order and acknowledgement boundaries where risk warrants; and keep the human-factors question in its own evidence stream. When a row cannot be filled from evidence, record the gap and resolve it through a requirement, an evidence request or further evaluation rather than an assumed rule.