Why Changing One Thing at a Time Matters

Published August 13, 2026 · Revised September 6, 2026

How controlled troubleshooting helps you actually learn what fixed the problem

One of the easiest ways to make troubleshooting confusing is to change too many things at once.

Back to Biomed Basics

What This Page Explains

This page covers:

The Simple Version

If you change one controlled variable and the symptom changes, you have learned something about that variable. If you replace a cable, move rooms, update software, reseat boards, and swap the battery before retesting, a successful result cannot tell you which action mattered. The equipment may return with the same fault because the actual cause was never isolated.

Before each test, write the question it should answer and decide what a pass or failure means. Keep the setup stable, record the result, and then choose the next change from that evidence. Safety comes first: when a hazardous condition requires several immediate corrective actions, make them, but document them honestly and do not claim a root cause that the combined intervention cannot prove.

Troubleshooting Is an Experiment

Think of each troubleshooting step as a small experiment.

You start with:

Problem present.

Then you change one variable.

Then you observe what happens.

If the problem disappears, that variable becomes important.

If nothing changes, you move on.

That creates useful evidence.

Example: Monitor Will Not Charge

Possible causes:

Poor approach:

Replace battery, clean contacts, update software, and replace power supply.

Monitor charges.

What fixed it?

No idea.

Better approach:

Install known-good battery.

Still no charge.

Now battery becomes less likely.

Clean and inspect contacts.

Still no charge.

Measure power supply output.

Out of specification.

Now you have a much stronger diagnosis.

Multiple Changes Hide the Cause

Suppose a ventilator fails flow calibration.

You:

Calibration passes.

You might say:

The new sensor fixed it.

But did it?

Maybe the old sensor was fine and the connector was loose.

Maybe the software reset cleared the problem.

Maybe cleaning the flow path fixed it.

Because everything changed at once, you cannot know.

Why This Matters Beyond Curiosity

Knowing what actually fixed the problem matters because it helps with:

If the same problem comes back next month, good evidence from the first repair can save a lot of time.

Known-Good Swaps Work Best One at a Time

Known-good substitution is powerful because it isolates a single component.

Example:

Original cable:

Failure.

Known-good cable:

Works.

That tells you something.

Now imagine you also changed:

at the same time.

The cable swap is no longer meaningful.

The value of known-good testing comes from controlling everything else.

Before-and-After Matters

Try to reproduce the problem before making the change.

Then repeat the same test afterward.

That gives you:

Before: Fail

Change one thing

After: Pass

That is strong evidence.

If you cannot reproduce the original failure, proving the repair becomes harder.

Example: Intermittent ECG Dropout

Complaint:

ECG drops when the cart moves.

You reproduce it.

Flex trunk cable.

Waveform disappears.

Now replace the cable.

Repeat exact movement.

Waveform remains stable.

That is a clean troubleshooting result.

Change the Most Informative Variable First

Changing one thing at a time does not mean you must move slowly.

Choose the test that gives you the most useful information.

If a device has a questionable external sensor, swapping a known-good sensor may eliminate several possibilities immediately.

A good test should divide the problem space.

Start With the Easy Variables

Common easy variables include:

These are often faster to test than opening the device.

Do Not Replace an Expensive Board as Your First “Variable”

If simpler possibilities remain, test them first.

Example:

SpO2 unavailable.

Possible causes:

Start outside.

A $100 sensor is a much better diagnostic variable than a $4,000 main board.

Software Changes Count as Variables Too

Technicians sometimes forget this.

If you:

you changed the system.

Those changes can affect symptoms.

Document them like you would a hardware replacement.

Rebooting Is Also a Variable

Power cycling may clear:

If the problem disappears after reboot, that is useful information.

Do not pretend nothing changed.

You changed the software state.

Reseating Connectors Is a Variable

This is a big one.

You open a device.

Disconnect and reconnect every harness.

Put it back together.

Problem disappears.

You may say:

Could not duplicate after inspection.

But in reality, you changed multiple connections.

One may have been loose.

That information is now lost.

Whenever practical, inspect and test suspicious connections deliberately rather than reseating everything immediately.

Cleaning Is a Variable

Cleaning a flow sensor, optical sensor, connector, or contact can absolutely fix a problem.

Document it.

Example:

Flow sensor contaminated. Cleaned per manufacturer procedure. Calibration subsequently passed.

That is better than:

Tested okay.

Calibration Is a Variable

If you calibrate a device before confirming the original failure, you may erase evidence of drift.

Example:

NIBP reads consistently 15 mmHg high.

You immediately calibrate it.

Now it reads correctly.

You fixed the issue, but you lost the opportunity to characterize the original error.

Sometimes that may not matter.

Other times it could.

Testing Order Matters

A useful sequence is:

  1. Reproduce the problem.
  2. Record the baseline.
  3. Change one variable.
  4. Repeat the same test.
  5. Record the result.
  6. Decide the next step.

That structure keeps your evidence clean.

Not Every Change Needs a Full Work Order Essay

You do not have to document every tiny action.

But record changes that affect the diagnosis.

Example:

Reproduced intermittent shutdown on battery. Installed known-good battery; failure remained. Inspected battery contacts and found loose negative terminal. Secured connection and repeated runtime/movement test with no shutdown.

That tells a clear story.

When Multiple Changes Are Reasonable

There are exceptions.

Sometimes the priority is not perfect diagnosis.

Examples:

If the manufacturer says:

Replace these three components together.

do that.

The rule is not absolute.

It is a troubleshooting principle.

Repair Kits

Manufacturers may sell an assembly or kit containing several components.

Replacing the whole kit may be appropriate.

You may never know which individual part was bad.

That is okay if the manufacturer designed the repair that way.

Document:

Replaced manufacturer service kit per procedure.

Do not pretend you isolated one component if you did not.

Safety Can Override Diagnostic Purity

Suppose you find:

You may replace several damaged components together.

That is appropriate.

Do not keep unsafe hardware installed just so you can run a prettier experiment.

Safety comes first.

Time Can Matter

Some equipment is critical to operations.

You may need to restore service efficiently.

There is a balance between:

Perfect root-cause isolation

and:

Reasonable, evidence-based repair.

The goal is not to turn every work order into a science project.

The goal is to avoid unnecessary uncertainty when it can easily be prevented.

Real-World Example: Battery Complaint

Device shuts off after 20 minutes.

You simultaneously:

Problem resolved.

Now you cannot tell whether:

Better:

Test original battery capacity first.

That one measurement might answer the entire question.

Real-World Example: Sensor Not Recognized

Device says:

Sensor Not Recognized.

You replace sensor and cable together.

Works.

Which was bad?

Unknown.

Better:

Known-good sensor with original cable.

Then:

Original sensor with known-good cable.

Now the failure can follow one component.

Real-World Example: Network Failure

Monitor will not connect.

You:

Now it connects.

You have no idea what was wrong.

Better:

Check link.

Check IP.

Check gateway.

Test cable.

Verify VLAN.

One variable at a time.

Real-World Example: Ventilator Calibration Failure

Flow calibration fails.

You first:

Clean sensor.

Retest.

Still fails.

Install known-good sensor.

Retest.

Still fails.

Inspect connector.

Bent pin found.

Now you know the problem was not contamination or the sensor.

The evidence narrowed the path.

Avoid the “Shotgun” Approach

Shotgun troubleshooting means changing many things hoping one works.

It can be tempting when:

But it usually teaches you less.

You may also introduce new problems.

Every Change Can Create Another Failure

When you open a device and change components, you can accidentally create:

The fewer unnecessary changes you make, the lower that risk.

Baseline Before Change

Whenever possible, record the state before touching it.

Examples:

Then you know what actually changed.

Keep a Mental Control Group

In an experiment, a control stays unchanged.

In troubleshooting, your baseline plays that role.

If:

Original condition = failure.

One change = pass.

You have a meaningful comparison.

Without a baseline, a passing result may not mean much.

This Helps With Repeat Failures

Suppose the device comes back six months later.

Work order says:

Replaced battery, cable, and power supply last time.

Not very useful.

Compare:

Original battery failed capacity at 38% of rated runtime. Known-good battery resolved shutdown. Replaced battery.

Now the next technician knows exactly what happened.

Common Mistakes

Replacing Several Parts at Once

You lose isolation.

Resetting Everything Before Testing

You destroy the baseline.

Reseating Every Connector Immediately

You may accidentally fix the problem without knowing why.

Updating Software During Hardware Diagnosis

Now there are multiple variables.

Failing to Reproduce the Original Problem

You cannot compare before and after.

Assuming the Last Change Fixed It

The actual cause may have been an earlier change.

A Useful Question Before Every Step

Ask:

What question will this change answer?

If you cannot explain what you expect to learn, consider whether the step is useful.

Another Useful Question

Before changing something, ask:

If the device starts working afterward, will I know why?

If the answer is:

No, because I am changing five things.

you may want to slow down.

What Did You Actually Prove?

You replace a battery and the device works.

What did you prove?

Maybe:

Device worked with the replacement battery.

To prove the original battery caused the failure, stronger evidence might include:

Now the diagnosis is much stronger.

Final Thoughts for Biomeds

Good troubleshooting is not about making the largest number of changes.

It is about making the most informative change.

Start with the symptom.

Establish a baseline.

Change one thing.

Repeat the test.

See what changed.

Then decide what comes next.

There will be times when changing multiple components is appropriate.

But when you are trying to understand a failure, control your variables whenever you can.

Because:

The device working again is good.

But knowing why it works again is even better.

That knowledge is what makes the next repair faster.

— Jake

Important Note

This page is an educational overview of troubleshooting methodology. Follow manufacturer service procedures, required repair kits, facility policies, safety requirements, and your authorized service scope. Safety-related repairs and manufacturer-defined multi-component procedures may appropriately require multiple changes at the same time.

Related Biomed Basics

Back to Biomed Basics