What This Page Explains
This page covers:
- What a symptom is
- What a cause is
- What a root cause is
- Why the distinction matters
- Why error codes are not always causes
- Why replacing a failed part may not solve the root cause
- How to avoid stopping too early
- How to document each level clearly
- Common mistakes
The Simple Version
A symptom is what someone observes, such as a monitor shutting down. A cause is the technical condition directly producing it, such as a power supply entering thermal protection. A root cause is the underlying reason that condition developed, such as blocked airflow from a clogged filter and poor installation clearance.
Keep evidence and certainty separate. Replacing the failed part may restore operation without proving why it failed. Not every routine age-related failure needs a formal investigation, but repeated, shared, safety-relevant, or costly failures deserve a deeper look at environment, accessories, process, configuration, and prior repair.
What Is a Symptom?
A symptom is what the device is doing wrong.
Examples:
- Will not power on
- Randomly shuts down
- SpO2 not reading
- NIBP measurement fails
- Battery not charging
- Network connection lost
- High airway pressure alarm
A symptom describes the problem.
It does not explain why it happened.
Start With the Symptom
Good troubleshooting starts here.
Instead of:
Power supply bad.
write:
Device will not power on from AC.
That keeps your mind open to multiple possible causes.
What Is a Cause?
A cause is the condition that directly produces the symptom.
Example:
Symptom:
Device will not power on.
Cause:
Internal power supply output is absent.
Now you have identified the immediate technical reason.
What Is a Root Cause?
The root cause explains why that failure happened.
Continuing the example:
Symptom:
Device will not power on.
Cause:
Internal power supply failed.
Possible root cause:
Cooling fan failed, causing repeated overheating and eventual power-supply damage.
Now you understand more than just the failed part.
Not Every Failed Part Is the Root Cause
This is one of the most important concepts.
Suppose a fuse is open.
Symptom:
Device dead.
Cause:
Fuse is open.
But why did the fuse open?
Possible root cause:
- Shorted power supply component
- Damaged wiring
- Motor fault
- Surge
If you replace only the fuse, the real problem may still exist.
Another Example: Battery
Symptom:
Device shuts down during transport.
Cause:
Battery connection opens intermittently.
Root cause:
Battery latch is worn and allows the battery to move.
Replacing the battery alone may not solve it.
Another Example: ECG Artifact
Symptom:
ECG waveform has intermittent artifact.
Cause:
Lead wire conductor is broken near the strain relief.
Root cause:
Repeated tight wrapping damaged the cable over time.
The immediate repair may be cable replacement.
The root cause may involve how cables are stored.
Why the Distinction Matters
If you stop at the symptom, you guess.
If you find the cause, you can usually repair the device.
If you understand the root cause, you may prevent the problem from returning.
That is the difference.
Error Codes Are Usually Symptoms or Clues
An error code may tell you:
Fan Speed Low.
That does not automatically mean:
Replace fan.
Possible causes include:
- Failed fan
- No fan power
- Loose connector
- Tach signal failure
- Board cannot read speed
The code tells you what the device detected.
You still need to find the cause.
Alarm Example
Alarm:
O2 Supply Pressure Low.
Symptom:
Device reports low supply pressure.
Cause could be:
- Low wall pressure
- Kinked hose
- Faulty sensor
Root cause depends on what created that condition.
Do not confuse the alarm with the diagnosis.
Cause vs Contributing Factor
Sometimes more than one thing contributes.
Example:
Device overheats.
Direct cause:
Cooling fan stopped.
Contributing factor:
Filter heavily clogged.
Root cause:
Preventive maintenance process failed to identify the airflow restriction.
Depending on the situation, there may be multiple contributing factors.
Root Cause Is Not Always a Single Part
Root cause can involve:
- Hardware
- Environment
- Workflow
- Configuration
- Maintenance
- User handling
Example:
Repeated cable failures may not be caused by defective cables.
The root cause may be:
Cables are being pinched under bed frames during transport.
Do Not Force a Root Cause When You Do Not Have Evidence
This matters too.
If all you know is:
Battery failed capacity test.
Do not invent:
Root cause was excessive charging cycles.
unless you have evidence.
Sometimes the correct conclusion is simply:
Battery degraded below acceptable capacity.
That is enough.
Technical Cause vs Operational Root Cause
There can be different levels of explanation.
Example:
Symptom:
Monitor disconnects from network.
Technical cause:
Ethernet cable intermittently opens.
Operational root cause:
Cable repeatedly gets pinched by the cart.
Both can be useful.
Root Cause Depends on the Question
Ask:
How deep do I need to go?
For a simple corrective repair, identifying the failed cable may be enough.
For repeated fleet failures, you may need to ask why the cables keep failing.
Context matters.
Repeated Failures Deserve Deeper Thinking
If the same issue occurs once:
Repair may be straightforward.
If it occurs ten times:
Ask why.
Patterns suggest a root cause beyond individual part failure.
Example: Repeated Battery Failures
Several devices have early battery failure.
Possible deeper causes:
- Wrong replacement battery
- Charging firmware issue
- Excessive heat
- Incorrect storage
- Bad battery lot
Replacing batteries repeatedly does not address the root cause.
Example: Repeated Fan Failures
Multiple units show overheating.
Individual cause:
Fan failure.
Fleet-level root cause might be:
- Dust-heavy environment
- Blocked installation
- Filter maintenance problem
The context changes the analysis.
Symptom Can Have Many Causes
Symptom:
Device will not power on.
Possible causes:
- Outlet
- Cord
- Fuse
- Power supply
- Battery
- Main board
The symptom alone does not tell you which one.
That is why isolation matters.
One Cause Can Create Many Symptoms
A single power-supply problem might cause:
- Random reboot
- Display flicker
- Battery charging failure
- Communication errors
Multiple symptoms can share one cause.
Look for common points.
Example: Power Rail Failure
Symptoms:
- Touchscreen freezes
- Network disconnects
- Device reboots
Cause:
5 V rail drops under load.
One electrical problem created several software-looking symptoms.
Do Not Repair the Symptom
This is the classic trap.
Symptom:
Device keeps rebooting.
Action:
Reboot the device.
That may temporarily remove the symptom.
It does not fix the cause.
Temporary Recovery vs Repair
If a reboot restores operation, you proved:
The device can recover after restart.
You did not prove:
The underlying failure is fixed.
Keep investigating recurring problems.
Component Replacement Does Not Automatically Equal Root-Cause Repair
Suppose you replace a damaged connector.
Why was it damaged?
If the cable is under constant tension, the new connector may fail again.
Sometimes the repair must address:
- Part
- Routing
- Strain relief
- Usage condition
Root Cause and Preventive Action
A useful root-cause finding often suggests a preventive action.
Example:
Root cause:
Battery connector loosens because mounting screws repeatedly back out.
Preventive action:
Correct torque and thread-locking method per manufacturer procedure.
Now you reduce recurrence.
Root Cause and Documentation
Good documentation separates observation from diagnosis.
Example:
Symptom
Monitor lost power during transport.
Cause
Battery connection opened intermittently during movement.
Root Cause
Battery latch worn and no longer retained pack securely.
That tells a clear story.
Avoid Writing Unsupported Root Cause
Weak:
Root cause: user abuse.
Unless you have evidence, that is speculation.
Better:
Housing cracked near connector; impact damage observed.
Document what you can prove.
Clinical Complaint May Already Contain a Diagnosis
Staff may say:
The sensor is bad.
Treat that as a hypothesis.
Actual symptom may be:
No temperature reading.
Your job is to isolate the cause.
Manufacturer Troubleshooting Trees Often Follow This Logic
A flowchart may move from:
Symptom
to:
Possible causes
to:
Tests
to:
Corrective action
That is the same concept in structured form.
Use Evidence to Move Down the Chain
Example:
Symptom:
No SpO2.
Test:
Known-good sensor also fails.
Now accessory becomes less likely.
Inspect connector.
Bent pin found.
That identifies cause.
Then ask:
Why bent?
If repeated connector damage exists, maybe cable handling is contributing.
Root Cause Does Not Always Mean Formal RCA
In Biomed, you may use “root cause” informally to mean:
The underlying reason the failure occurred.
A formal organizational Root Cause Analysis is a separate process and may involve:
- Risk management
- Patient safety
- Leadership
Do not confuse everyday troubleshooting with formal incident RCA.
Real-World Example: NIBP Failure
Symptom:
Cuff will not inflate.
Cause:
Hose leak.
Root cause:
Hose repeatedly kinked at cart hook.
Repair:
Replace hose.
Prevention:
Correct routing/storage.
Real-World Example: Monitor Reboot
Symptom:
Random reboot.
Cause:
Battery contact intermittently opens.
Root cause:
Battery latch wear.
Repair:
Replace latch assembly.
Verification:
Repeated transport simulation without reboot.
Real-World Example: Ventilator High Temperature
Symptom:
High internal temperature alarm.
Cause:
Cooling airflow insufficient.
Root cause:
Filter heavily clogged.
Repair:
Replace/clean filter per procedure.
Verification:
Extended operation with normal temperature.
Real-World Example: Network Failure
Symptom:
Monitor missing from central.
Cause:
Wrong gateway configuration.
Root cause:
Configuration lost after board replacement.
Repair:
Restore approved network settings.
Now the failure makes sense from start to finish.
Real-World Example: Repeated Fuse Failure
Symptom:
Device dead.
Cause:
Fuse open.
Replace fuse:
It opens again.
Root cause:
Shorted component on power board.
The fuse was not the real repair.
Common Mistakes
Treating the Symptom as the Cause
“Will not power on” is not a diagnosis.
Treating the Failed Part as the Root Cause Automatically
Ask why it failed.
Assuming the Error Code Names the Cause
It usually names what was detected.
Going Too Deep Without Evidence
Do not invent root causes.
Stopping After Temporary Recovery
A reboot is not necessarily a repair.
Ignoring Repeated Patterns
Recurrence often points deeper.
A Useful Troubleshooting Framework
Ask:
What do I observe?
That is the symptom.
Then:
What directly caused that condition?
That is the cause.
Then:
Why did that cause exist?
That may be the root cause.
Keep going only as far as the evidence and situation require.
Another Useful Question
Ask:
If I replace this part, what would make the new part fail the same way?
That question often reveals whether you have reached the root cause.
What Did You Actually Prove?
If a fuse is open, you proved:
The fuse is open.
You did not prove:
The fuse itself was the original failure.
If a battery fails a capacity test, you proved:
The battery no longer meets required capacity under that test.
You may not know exactly why it degraded.
Keep the conclusion aligned with the evidence.
Final Thoughts for Biomeds
Troubleshooting gets much cleaner when you separate:
Symptom
from:
Cause
from:
Root Cause.
The symptom is what you see.
The cause is what directly created it.
The root cause explains why that failure happened.
Sometimes finding the cause is enough.
Sometimes repeated failures mean you need to go deeper.
The important thing is not to jump from:
Device shut off.
to:
Bad battery.
without evidence.
Start with what you can observe.
Isolate the cause.
Then ask whether there is a deeper reason that matters.
That is how you move from simply swapping parts to actually understanding the failure.
— Jake
Important Note
Root-cause depth should match the equipment risk, failure pattern, manufacturer guidance, and facility process. Formal incident investigations or organizational root-cause analyses may require involvement from risk management, patient safety, clinical leadership, manufacturers, or other departments beyond normal corrective maintenance troubleshooting.