How to Avoid Confirmation Bias While Troubleshooting

Why the first explanation that makes sense can quietly lead you toward the wrong repair

Troubleshooting is supposed to be about evidence.

Published August 13, 2026 · Revised September 6, 2026

Back to Biomed Basics

What This Page Explains

This page covers:

The Simple Version

A familiar symptom naturally suggests a familiar cause. Thinking “this may be the battery” is a useful starting hypothesis. Confirmation bias begins when every observation is interpreted as proof of that answer and conflicting evidence is ignored. The goal of the next test should be to distinguish the battery from other reasonable causes, not merely to confirm the first idea.

Before testing, write down what result would support the theory and what result would weaken it. Keep at least one alternative explanation alive. A known-good substitution, voltage-under-load check, or comparison with another device is valuable because the result can move the diagnosis in either direction.

Worked Example: “It Has to Be the Battery”

A monitor shuts down when unplugged, so the battery seems obvious. But the service screen identifies the pack, reports charge, and the same battery powers another approved monitor normally. That evidence should reduce confidence in the battery theory and redirect attention to contacts, power-path switching, host measurement, configuration, or excessive load.

If you replace the battery anyway and the symptom briefly disappears, do not stop at the satisfying result. Repeat the unplug transition, inspect the original battery in a controlled test, and ask whether reseating the pack—not replacing it—changed the outcome. Verification should challenge the repair story as hard as the initial diagnosis.

A Hypothesis Is Not a Diagnosis

Suppose a patient monitor randomly shuts off.

You think:

Battery.

That is a hypothesis.

It may be a very reasonable one.

But other possibilities include:

Until you test, you do not know.

Keep your language accurate.

Instead of:

Bad battery.

Think:

Battery is currently my leading suspect.

That keeps the door open.

Why Experience Can Create Bias

Experience is one of the greatest advantages a technician develops.

You see patterns.

You remember:

Every time these do this, it is usually the power supply.

That can save a huge amount of time.

But experience can also create shortcuts.

You may see a familiar error and immediately assume the same failure is happening again.

Sometimes you are right.

Sometimes the symptom is identical but the cause is completely different.

Experience should guide your first test.

It should not determine the answer before the test happens.

The Last Repair Is Powerful

Imagine you repaired three identical monitors last month.

All three had:

Battery Not Recognized.

Every one needed a battery.

Today another monitor arrives with the same message.

Your brain immediately says:

Battery.

Reasonable.

Then you install a known-good battery.

Same error.

At that moment, the original theory should become weaker.

If instead you think:

Maybe this known-good battery is also bad.

you may be protecting your theory instead of following the evidence.

That is confirmation bias.

Contradictory Evidence Is Valuable

Technicians naturally like results that support the diagnosis.

But the result that disproves your theory may be even more useful.

Example:

Theory:

Battery is bad.

Test:

Known-good battery produces the same failure.

That is not a disappointing test.

That is excellent information.

You just eliminated or weakened a major possibility.

Good troubleshooting welcomes evidence that says:

You're looking in the wrong place.

Do Not Explain Away Every Failed Test

This is one of the easiest traps to fall into.

Theory:

Main board is bad.

But:

If you keep finding reasons why those results “do not count,” you may be defending the conclusion.

Sometimes a test is imperfect.

But when several independent findings contradict your theory, reconsider it.

Build More Than One Possible Explanation

Before replacing an expensive part, list a few plausible causes.

Example:

Device will not charge.

Possible causes:

  1. Battery
  2. Battery contacts
  3. Charger circuit
  4. Power supply
  5. Battery communication
  6. Software/configuration

Now ask:

What test separates these possibilities?

That is much better than selecting one and trying to make the facts fit.

Start With the Symptom

The safest anchor is the actual symptom.

Complaint:

Monitor shuts off during transport.

Not:

Monitor has a bad battery.

Complaint:

NIBP fails midway through measurement.

Not:

Pump motor is bad.

Complaint:

ECG disappears when cable moves.

Not:

Acquisition board failure.

The symptom is something you observed or were told happened.

The diagnosis is your explanation.

Do not confuse them.

Use Tests That Could Prove You Wrong

This is a powerful habit.

If your theory is:

The SpO2 sensor is bad.

Do not just find a test that the sensor fails.

Try:

Now the failure can either:

follow the sensor

or:

stay with the monitor.

You designed a test that can prove your original theory wrong.

That is strong troubleshooting.

Known-Good Testing Fights Bias

Known-good substitution is especially useful because it creates a direct comparison.

Example:

You believe the battery is bad.

Install known-good battery.

Problem remains.

Now your theory has less support.

Do not immediately order another battery because:

Maybe both are bad.

Verify your known-good reference if necessary, then move on.

Changing One Thing at a Time Helps Too

Suppose you believe a device has a software problem.

You:

The problem disappears.

Now you tell everyone:

Software update fixed it.

Did it?

You changed four variables.

You cannot know.

Changing one thing at a time prevents your preferred explanation from taking credit for a repair it may not have caused.

Parts Can Create False Confidence

This happens frequently.

You replace the part you suspected.

Device now works.

Diagnosis confirmed?

Maybe.

But think about what else happened during the repair.

You may have:

Any of those could have affected the symptom.

The replacement is strong evidence if the failure clearly disappears and can be tied to the component.

But do not overstate certainty when several variables changed.

Repeat the Failure Before Replacing the Part

Whenever practical, reproduce the problem first.

Then replace the suspect component.

Then perform the same test again.

That creates:

Before repair: Fail

After repair: Pass

That is much stronger evidence.

If you never reproduced the original failure, it is harder to prove what fixed it.

Failure Following the Part Is Strong Evidence

For interchangeable components:

Original module on Device A:

Fails.

Known-good module on Device A:

Passes.

Original module on Device B:

Fails.

That is excellent evidence.

The failure follows the module.

Your theory now has real support.

Failure Staying With the Device Is Also Strong Evidence

Original module on Device A:

Fails.

Known-good module on Device A:

Also fails.

Both modules work on Device B.

The failure stays with Device A.

Now stop blaming the module.

That is the evidence telling you where to look.

Be Careful With Error Codes

Error codes can create instant bias.

Device displays:

Flow Sensor Error.

Your brain says:

Flow sensor.

But what does the device actually know?

It may only know:

The signal from the flow measurement system is outside the expected range.

Possible causes might include:

The error code is a clue.

Not necessarily a diagnosis.

Vendor Recommendations Can Create Bias Too

Technical support says:

Usually that's the main board.

Now every test you perform may subconsciously be aimed at confirming the board failure.

Remember:

“Usually” is not:

“Definitely.”

Ask:

Use vendor experience.

Do not let it replace your own evidence.

Work Orders Can Bias You Before You Even Touch the Device

Complaint:

Replace battery.

You have not even seen the device yet.

But now you are mentally primed for a battery problem.

Try translating the work order back into a symptom.

Maybe the actual story is:

Device powered off while unplugged.

That could be battery-related.

But you still need to test.

Another Technician's Diagnosis Can Bias You

Previous note:

Suspect main board.

Treat that as information.

Not fact.

Ask:

You may agree completely.

Or you may find the evidence points somewhere else.

Expensive Parts Make Bias Worse

Once you have ordered a $4,000 board, you want that board to be the answer.

That is human.

If the device still fails afterward, there is a temptation to explain it away:

Maybe the replacement board is bad.

Sometimes replacement parts really are bad.

But first consider:

Was the original diagnosis wrong?

The more money or effort invested in a theory, the harder it can become to abandon it.

This Is Sunk Cost Too

You have spent:

Three hours troubleshooting the battery system.

Now you notice:

The unit reboots even with the battery completely removed while on AC.

That is major contradictory evidence.

Do not think:

I've already spent three hours on the battery. I need to finish proving it.

Those three hours are already spent.

Follow the evidence now.

Look for the Common Cause

Imagine five devices develop the same network failure at the same time.

You could assume:

Five network cards failed.

Technically possible.

But improbable.

Ask what those devices share:

Looking for common factors prevents device-level bias.

Ask Yourself What Else Could Cause This

This is one of the easiest techniques.

When you think you know the answer, literally ask:

What else could produce this exact symptom?

You do not need 20 possibilities.

Come up with two or three.

Then test which explanation fits best.

Try to Disprove Your Favorite Theory

This feels backward.

It is extremely effective.

Theory:

Bad power supply.

What would prove that theory wrong?

Maybe:

Supply maintains every required rail within specification during the failure.

If that happens, stop blaming the power supply.

You just saved yourself a part.

Use Specifications, Not Feelings

Suppose a battery lasts:

55 minutes.

You think:

Seems short.

Manufacturer requirement:

At least 45 minutes under the specified test.

The battery passes.

Your feeling that it seems short should not override the specification.

Likewise, if the specification requires:

90 minutes

then:

It seems good enough.

does not make it pass.

Objective limits help reduce bias.

Do Not Move the Goalposts

Theory:

Battery is bad because it shuts down below 50%.

Test:

Device runs correctly to 10%.

Then you say:

Well, it still dropped faster than I expected.

You changed the reason for your diagnosis after the evidence contradicted it.

That is moving the goalposts.

Define what result would support or reject the theory before the test when possible.

Write Down the Expected Result

Before a key test, ask:

If my theory is correct, what should happen?

Example:

Theory:

ECG trunk cable is intermittent.

Prediction:

Flexing the cable near the connector should cause dropout.

Test:

Flex cable.

No dropout.

Now the theory loses strength.

This simple habit makes your reasoning much more objective.

Separate Evidence Into Three Buckets

When a repair gets complicated, make three mental lists.

Known

Things you have proven.

Example:

Suspected

Things that may be true.

Example:

Unknown

Questions you still need to answer.

Example:

This prevents suspicions from quietly becoming “facts.”

Real-World Example: Monitor Randomly Shuts Off

Initial thought:

Battery.

Test original battery:

Shutdown occurs.

Theory seems stronger.

Test known-good battery:

Shutdown still occurs.

Now battery theory weakens.

Observe shutdown occurs during AC-to-battery transition.

Now investigate:

Without that willingness to abandon the first theory, you might have ordered three batteries.

Real-World Example: NIBP Failure

Complaint:

NIBP pump sounds weak.

Initial thought:

Pump motor.

But analyzer shows pressure rises normally until a valve suddenly vents.

Known-good pump assembly behaves the same way.

Now the motor theory does not fit.

Valve or control behavior deserves more attention.

Listen to the test, not the original impression.

Real-World Example: Ventilator Flow Sensor Error

Error says:

Flow Sensor Calibration Failed.

Initial thought:

Flow sensor.

New sensor:

Still fails.

Known-good sensor:

Still fails.

Original sensor passes on another ventilator.

The sensor theory is finished.

Move toward:

Do not order sensor number four.

Real-World Example: Monitor Does Not Send to EMR

Initial assumption:

Network problem.

Device:

Other devices on same network transmit normally.

Integration server shows this monitor is sending data but patient association is missing.

The evidence moved the problem from:

network

to:

integration/patient association.

That is exactly what should happen.

Common Mistakes

Falling in Love With the First Diagnosis

Keep it as a hypothesis.

Only Performing Confirming Tests

Design tests that could prove you wrong.

Ignoring Contradictory Evidence

Contradictions are useful.

Trusting the Error Code Too Much

It tells you what was detected.

Replacing the Same Part Repeatedly

Question the diagnosis.

Letting Previous Repairs Decide the Current One

Similar symptom does not guarantee similar cause.

Changing Several Variables at Once

You lose evidence.

Confusing Experience With Proof

Experience points you toward the test.

It does not replace it.

A Useful Troubleshooting Habit

Before ordering a part, ask yourself:

What evidence supports this diagnosis?

Then:

What evidence does not fit it?

Then:

What other explanation could fit both?

That third question is where a lot of difficult repairs get solved.

Another Useful Question

Ask:

What result would make me change my mind?

If the answer is:

Nothing.

you are no longer troubleshooting.

You have decided.

Good troubleshooting always leaves room for the evidence to change the conclusion.

What Did You Actually Prove?

This question appears over and over in Biomed Basics because it matters.

Did you prove:

Did you prove:

Did you prove:

Keep your conclusions the same size as your evidence.

Final Thoughts for Biomeds

Troubleshooting requires opinions.

You need to form theories.

You need to recognize patterns.

You need to say:

I think this is probably the power supply.

That is not bad troubleshooting.

The mistake is turning:

probably

into:

definitely

before the evidence supports it.

Use your experience to decide where to look first.

Then let the results decide where you look next.

Welcome the test that proves you wrong.

Change your mind when the facts change.

And remember:

The goal of troubleshooting is not to prove that you were right.

The goal is to find out what is actually wrong.

— Jake

Important Note

This page is an educational overview of troubleshooting reasoning. Medical equipment diagnosis and repair should follow current manufacturer documentation, facility procedures, appropriate safety requirements, validated test methods, and your authorized service scope.

Related Biomed Basics

Back to Biomed Basics