A device that stops and displays an error code is a manageable problem. Someone notices, someone intervenes, and the log usually explains itself. The failures that produce serious harm tend to be the quiet ones: a flow sensor drifting slowly inside its plausible range, an alarm condition the detection logic never classified as one, a software state reached only by an unusual sequence of inputs. Nothing is displayed, nothing sounds, and the clinical record shows a patient deteriorating for reasons nobody can attribute. Investigating that class of failure means asking a different set of questions, and different documents.
Announced failure and unannounced failure
IEC 60601-1 frames medical electrical equipment around basic safety and essential performance — the performance whose loss or degradation would create unacceptable risk. Detected degradation can be annunciated and acted on. Undetected degradation cannot.
So the first analytical question is not what broke but whether the device was capable of knowing it had broken. A subsystem with no independent check on its own output fails silently by construction, and whether that was an accepted design decision is answerable from the risk file.
Software faults are state faults
Firmware defects that survive testing are rarely simple arithmetic errors. They are race conditions, unhandled transitions between operating modes, boundary conditions at the edge of a valid range, faults in error handling that are themselves never exercised, and interactions between concurrent tasks that occur only under specific timing.
IEC 62304 governs the software lifecycle and assigns a safety class according to the harm a software failure could permit, which in turn sets the rigour required of architecture, unit verification and integration testing. It also requires that software of unknown provenance — operating systems, libraries and components not developed under the lifecycle — be identified, and its known anomalies evaluated.
Sensor drift and the calibration record
Pressure, flow and optical sensors degrade gradually, and gradual degradation is the hardest kind to see. A reading that is wrong by a small margin and still inside the expected physiological range prompts no alarm and no suspicion; clinicians reasonably treat the number as true.
The investigative material is calibration and verification history, the manufacturer's stated accuracy and the conditions under which it holds, any shock or fluid-ingress event in the service history, and comparison against an independent measurement of the same parameter recorded elsewhere.
Alarm systems fail in several distinct ways
IEC 60601-1-8 sets out the collateral requirements for alarm systems: priority assignment reflecting urgency and onset, consistent auditory and visual characteristics, and defined inactivation states for pausing or silencing audio.
The failure modes are correspondingly varied. The condition may have fallen outside the detection logic, so no alarm existed to sound. The alarm may have fired at a lower priority than the situation warranted. It may have been paused, silenced or its limits widened earlier, the change persisting past the point anyone remembered making it. Or it may have annunciated into a room already saturated with alarms.
Distributed alarms and the responsibility gap
Many alarms now travel to a phone, pager or central station through middleware. That path introduces delivery failure, escalation delay and configuration errors, none of which appear on the device.
It also crosses an ownership boundary. The device may have annunciated exactly as specified while the notification never reached anyone, and establishing that requires the middleware and network logs, not the device log.
Power management and interference
Brownout behaviour is a classic silent fault: a supply sag long enough to disturb a processor but too short to be recorded as a shutdown can produce a reset, a corrupted setting or a lost alarm state with no entry in any log.
Electromagnetic interference behaves similarly. IEC 60601-1-2 sets immunity requirements and test levels, but a clinical environment can present combinations no laboratory sequence reproduces, which is why an EMI hypothesis is argued from susceptibility testing and environment survey rather than from the log.
Reproducing an intermittent fault honestly
Bench testing that fails to reproduce a fault is routinely offered as proof the fault never occurred. It is not. It establishes only that the conditions attempted did not produce it.
Credible testing states the conditions it recreated and the ones it could not, uses exemplar units of the same build and configuration, and treats a negative result as a bounded finding. Where a fault depends on timing, temperature, supply quality or a sequence of user inputs, absence of reproduction carries little weight unless the relevant variable was actually varied.
The design record
Design controls require a documented development history: design inputs and outputs, verification that outputs met inputs, validation that the device meets user needs in actual or simulated use, and a record of design changes with the analysis supporting each one.
Alongside it sits the risk management file required by ISO 14971 — hazard identification, risk estimation, the controls selected, and verification that those controls are both implemented and effective. Where a hazard appears in that file with a control that the device as built does not implement, the gap tends to be dispositive.
Post-market surveillance
Complaint handling, trending and corrective and preventive action are quality system obligations, not optional practice. Reporting under 21 CFR Part 803 adds a further trail, with manufacturer reports due within a short defined window and shorter still where remedial action is required, and separate obligations on user facilities.
The FDA's MAUDE database makes some of that visible from outside. It is a screening tool built from unverified narratives, not proof, but a recurring failure description across reports predating an event goes to what was known and when.
This article is general technical orientation, not a failure analysis, an engineering opinion, or advice on any specific matter. Determining the cause of a particular incident requires hands-on examination by a credentialed expert.