BioDeviceHub
Engineer's Guide/General Practice

Troubleshooting Method

The six-step structured approach behind every per-device troubleshooting guide on this site, plus how to handle a fault that won't reproduce.

The same structured approach applies whether the device is a ventilator or an infusion pump - this is the pattern behind every per-device troubleshooting guide on this site, and it holds up because it forces verification at each step instead of letting an assumption from step one silently carry through to step five.

The six steps

  1. Reproduce and record the exact symptom, error code/message, and the operating conditions present when it occurred - don't start disassembling on a secondhand description. Ask specifically what mode the device was in, what accessory was attached, and whether the fault is consistent or intermittent.
  2. Isolate the subsystem using the documented root cause for that symptom (power, sensor, mechanical, software) - swapping parts before isolating wastes time and consumables, and it also destroys the evidence trail you might need if the fault turns out to be a pattern worth escalating (see Chapter 09).
  3. Run the built-in self-test or manufacturer diagnostic if one exists; it usually narrows the fault faster than manual probing and often exposes an internal fault code that never surfaces during normal clinical operation.
  4. Service or replace the specific component identified - the least invasive fix that resolves the confirmed root cause, not the first plausible-looking part. Replacing a board when a connector was actually at fault costs real money and doesn't fix anything if the connector fails again.
  5. Re-verify with the same test that originally caught the fault before returning the device to clinical use - not a different, easier test that happens to pass.
  6. Log the repair - symptom, root cause, part replaced, and verification result - so the next tech isn't starting from zero.

When the fault won't reproduce

An intermittent fault that won't reproduce on the bench is one of the genuinely hard cases, and the wrong response is to conclude "no fault found" and return the device to service unchanged. Better approaches: extend the observation window rather than a single quick test cycle, try to replicate the exact reported conditions (patient cable routing, specific accessory, specific mode) rather than a generic functional check, and check connector/cable continuity under gentle flexing - a huge share of "intermittent" complaints are cable-level and only show up under mechanical stress that a static bench test never applies.

Distinguishing a device fault from a use error

Before concluding a device is faulty, rule out that the reported steps were actually followed as intended - see Chapter 19 for the fuller treatment of this, but the short version is: reproduce the operator's exact sequence before you reproduce your own expected sequence.