The Troubleshooting Process: Observe, Isolate, Test, Verify

A practical framework for working through medical equipment problems without guessing

Good troubleshooting is not:

Published August 16, 2026 · Revised September 6, 2026

Back to Biomed Basics

What This Page Explains

This page covers:

The Simple Version

Observe what is actually happening instead of accepting the reported diagnosis. Isolate the symptom to a function, accessory, subsystem, or operating condition. Test a specific theory with evidence that can support or reject it. Then verify that the original complaint is gone and that the complete affected function meets its return-to-service requirements.

The four steps are simple, but their order prevents wasted work. Replacing a battery before reproducing a shutdown skips observation and isolation. Powering the unit on once after repair skips verification. A disciplined process keeps the evidence connected to the decision.

Worked Example: Monitor Shuts Off When Unplugged

Observe by confirming the monitor operates on AC and recording exactly what happens when AC is removed. Isolate by checking whether the battery is recognized, charged, seated, and able to support another compatible device, using approved substitutions when permitted. Test the strongest theory with battery data, voltage-under-load information, contacts, and the service procedure rather than guessing from the icon.

After correcting the cause, verify more than startup. Charge as required, run the specified battery or runtime test, repeat the unplug transition, confirm charging and alarms, and check the functions disturbed during service. Document the complaint, measurements, repair, and final results so the next technician can see what was actually proven.

Step 1: Observe

Before touching anything, understand the symptom.

Do not begin with:

What part should I replace?

Begin with:

What is actually wrong?

That may sound obvious, but many bad repairs start with an assumed diagnosis instead of an observed symptom.

Complaint vs Symptom

Clinical complaint:

The battery is bad.

Actual symptom:

The monitor shuts off when unplugged.

Those are not the same thing.

The battery is a possible cause.

The shutdown is the symptom.

Keep those separate.

Another Example

Complaint:

The SpO2 board is bad.

Actual symptom:

The monitor says SpO2 sensor not detected.

Possible causes include:

If you begin with the assumed diagnosis, you may replace a perfectly good board.

Ask Better Questions

Useful questions include:

You are trying to turn:

It doesn't work.

into a specific technical symptom.

Look at the Device Before Changing It

Observe:

Do not immediately reboot.

The current failed state may contain useful evidence.

Write Down the Exact Error

If the device shows:

Error 234 — Module Communication Lost

do not document:

Communication error.

The exact message may matter later.

Take note of:

Reproduce the Symptom

If safe and practical, try to reproduce what staff saw.

If the complaint is:

Shuts down when unplugged.

Unplug it under controlled conditions.

If the complaint is:

ECG drops when cart moves.

Move the cable or cart safely while monitoring the signal.

Reproducing the failure gives you a much stronger starting point.

Observe Before Repairing

A good first question is:

Can I describe the failure clearly without guessing at the cause?

If yes, you are ready to isolate it.

Step 2: Isolate

Once you understand the symptom, narrow down where the failure is.

This is where troubleshooting becomes much more efficient.

Think in Sections

Break the system into smaller pieces.

Example:

No SpO2 reading.

Possible path:

Simulator / Patient

↓

Sensor

↓

Cable

↓

Connector

↓

SpO2 Module

↓

Main Device

Instead of asking:

Why doesn't SpO2 work?

ask:

Which section of this path is failing?

Device vs Accessory vs Infrastructure

A useful first isolation is:

Example:

Monitor missing from central station.

Possible areas:

Device

Network interface or configuration.

Accessory

Ethernet cable.

Infrastructure

Wall jack, switch, server, central station.

Do not automatically blame the box in front of you.

Find the Last Known-Good Point

Ask:

Where is the last place I know the function is working correctly?

Example:

Monitor displays vital signs correctly.

Integration gateway receives the measurements.

EMR does not.

You have already proven a large part of the path.

The problem is likely downstream from the gateway.

Use Known-Good Components

Known-good substitution is one of the best isolation tools.

Suspect sensor fails.

Known-good sensor works.

Suspect sensor fails on another device.

Now the failure follows the sensor.

That is strong evidence.

Move the Problem

You can isolate by moving:

Ask:

Does the problem follow the component or stay with the system?

Example: Network Failure

Monitor A fails in Room 10.

Monitor A works in Room 11.

Monitor B also fails in Room 10.

The problem stays with the room.

That strongly points away from Monitor A.

Break Complicated Systems Into Layers

A communication problem might involve:

  1. Physical connection
  2. Network configuration
  3. Server connection
  4. Application
  5. Clinical workflow

Test one layer at a time.

Do not troubleshoot the EMR if the Ethernet cable has no link.

Look for Common Points

If one device fails, consider the device.

If twenty devices fail simultaneously, consider what they share.

Possible common points:

The scale of the failure is useful evidence.

Isolation Is About Reducing Possibilities

At the beginning, you may have ten possible causes.

A good isolation step may reduce that to three.

The next one reduces it to one.

That is what you want.

Step 3: Test

Once you have narrowed the problem, test your hypothesis.

This is different from guessing.

A Test Should Answer a Question

Bad test:

I'll reboot it and see what happens.

Better:

I want to know whether the software state is causing the freeze.

Now the reboot has a purpose.

Ask Before Every Test

What question will this test answer?

If you cannot answer that, the test may not be useful.

Example: Battery

Hypothesis:

Battery is causing shutdown.

Test:

Install known-good battery and reproduce AC-to-battery transition.

Question:

Does the shutdown still occur with a known-good battery?

That is useful.

Compare Expected vs Actual

A test is most useful when you know what should happen.

Example:

Power supply expected:

24 VDC.

Measured:

12 VDC.

That is meaningful because you have a reference.

Without knowing expected behavior, a measurement is just a number.

Use the Right Test Equipment

Depending on the device, testing may require:

Use the tool that answers the question.

Change One Thing at a Time

This is one of the most important troubleshooting habits.

Do not:

all at once.

If the problem disappears, you will not know why.

Change one variable.

Retest.

Observe.

Try to Prove Yourself Wrong

Suppose you think:

The cable is bad.

Do not only look for evidence that supports that idea.

Ask:

What test would show me the cable is actually good?

For example:

Suspect cable works perfectly on another known-good device.

Now your original theory is weaker.

Good troubleshooting is not about proving your first idea right.

It is about finding what is actually wrong.

Repeat the Test

One successful cycle may not be enough.

Especially for intermittent failures.

If the complaint occurred every few cycles, repeat the condition.

Examples:

Make the test reflect the failure pattern.

Test Under the Failure Condition

If the problem happens:

test under those conditions.

A device that passes an easier condition may still fail clinically.

Use Logs as Evidence

Logs can help support your test.

Example:

Flex battery connection.

Device reboots.

Log shows:

Battery Communication Lost.

Repeat.

Same result.

Now the physical behavior and log evidence support each other.

Measurements Should Be Specific

Instead of:

Voltage good.

record:

Power supply output measured 24.1 VDC with device idle and 23.9 VDC under load.

That is much more useful.

A Passing Test Does Not Always Eliminate Every Cause

If a power supply shows correct voltage at idle, it may still fail under load.

Ask:

What did the test actually prove?

Keep the conclusion proportional to the evidence.

Step 4: Verify

Finding the problem and replacing the part is not the final step.

Now you need to prove the device works correctly again.

Verification Is Different From Troubleshooting

Troubleshooting asks:

What is wrong?

Verification asks:

Is it actually fixed?

Those are separate jobs.

Recreate the Original Complaint

This is often the best verification.

Complaint:

Monitor shuts off when unplugged.

Repair:

Battery contact repaired.

Verification:

Repeated AC-to-battery transitions with no shutdown.

That directly proves the original symptom is resolved under the tested conditions.

Test the Actual Function

If you repaired:

test that exact function.

Do not stop because the device boots.

Follow Manufacturer Procedures

Use required:

as specified by manufacturer and facility procedures.

Verify You Did Not Create a New Problem

After repair, check:

Service work can create new failures.

Example

You replace a display assembly.

Screen works.

But you accidentally leave the speaker cable disconnected.

The original repair succeeded.

The device still cannot return to service.

Verify Configuration After Software or Board Work

Check relevant:

A device can pass hardware testing and still be incorrectly configured.

Verify Intermittent Repairs More Aggressively

If the original failure was intermittent, test enough cycles to create reasonable confidence.

A single successful test after an intermittent repair proves very little.

Document the Verification

Good note:

Replaced failed SpO2 trunk cable. Verified stable simulator reading during repeated cable movement. No signal dropout observed.

Weak note:

Fixed.

Document what you proved.

Putting the Four Steps Together

Example 1: Monitor Will Not Power On

Observe

No display.

No LEDs.

No charging indicator.

Isolate

Outlet good.

Power cord good.

AC reaches internal power supply.

Power supply output absent.

Test

Verify correct input to supply.

Verify output remains 0 VDC.

Repair

Replace failed supply according to manufacturer procedure.

Verify

Power-up normal.

Battery charging normal.

AC/battery transition normal.

Required functional and safety testing passes.

That is a complete troubleshooting process.

Example 2: SpO2 Sensor Not Recognized

Observe

Exact message:

SpO2 Sensor Not Detected.

Isolate

Known-good sensor also fails.

Both sensors work on another monitor.

Problem stays with original monitor.

Test

Inspect monitor connector.

One contact pushed back.

Repair

Repair connector according to approved procedure.

Verify

Both known-good and original compatible sensors recognized.

Simulator reading stable.

No dropout during repeated connection cycles.

Example 3: Monitor Missing From Central Station

Observe

Monitor works locally.

No central connection.

Isolate

Ethernet link active.

Monitor works in another room.

Known-good monitor also fails at original location.

Test

Failure stays with network location.

Escalate

Work with IT to investigate wall jack/switch infrastructure.

Verify

Monitor appears correctly at central station after infrastructure repair.

Notice that Biomed did not need to replace anything.

Troubleshooting still succeeded.

Example 4: Ventilator High-Pressure Alarm

Observe

High airway pressure alarm.

Isolate

Analyzer confirms pressure is actually high.

Alarm system is functioning.

Test

Inspect circuit.

Filter heavily restricted.

Repair

Replace appropriate disposable/accessory according to procedure.

Verify

Pressure returns to expected range.

Alarm activates appropriately when controlled high-pressure condition is introduced.

The alarm was never the failure.

Example 5: Device Randomly Reboots

Observe

Reboots only during transport.

Isolate

Runs normally on AC.

Battery capacity passes.

Movement reproduces reboot.

Test

Manipulate battery interface.

Reboot occurs consistently.

Repair

Correct battery contact/latch issue.

Verify

Repeated transport-style movement and power transitions produce no reboot.

The random problem became repeatable.

The Troubleshooting Loop

Sometimes the first test does not identify the failure.

That is normal.

The process becomes a loop:

Observe

↓

Isolate

↓

Test

↓

New information

↓

Observe Again

↓

Isolate Further

↓

Test Again

You may cycle through those steps several times before reaching the cause.

Troubleshooting is not always a straight line.

Symptoms, Causes, and Root Causes

Keep these separate.

Example:

Symptom

Monitor shuts down during transport.

Cause

Battery contact intermittently opens.

Root cause

Battery latch is worn and allows movement.

Each level answers a different question.

Do not stop too early if understanding the underlying reason matters.

Do Not Let the Error Message Do the Thinking for You

Error:

Fan Failure.

That may mean:

Use the error to guide isolation.

Do not treat it as a parts order.

Do Not Let the Last Repair Bias You

Suppose this model:

Always has bad batteries.

Maybe.

But this one may have a charging-board problem.

Experience should help you choose tests.

It should not replace testing.

Use the Simplest Useful Test First

Good troubleshooting usually begins with:

before expensive internal replacement.

Do not start by replacing the hardest part to access.

External Before Internal

When practical, rule out:

before opening the device.

External components fail often and are easier to isolate.

Common Mistakes

Starting With the Part

Start with the symptom.

Changing Too Many Things

You lose the cause.

Ignoring the Original Conditions

Recreate the failure environment.

Assuming the Error Code Is the Diagnosis

It is evidence.

Stopping When the Device Powers On

Verify the actual function.

Not Using Known-Good References

Comparison is powerful.

Testing Without Knowing the Expected Result

Know what should happen.

Forgetting to Verify

Repair completion is not the same as repair proof.

A Useful Troubleshooting Checklist

Before returning to service, ask:

Observe

Isolate

Test

Verify

That is a strong basic framework.

The Most Important Question

At every step, ask:

What did I actually prove?

If you swapped a cable and the problem disappeared, what did that prove?

If the device passed self-test, what did that prove?

If it worked for ten minutes, what did that prove?

Keep the conclusion the same size as the evidence.

That habit alone makes troubleshooting much stronger.

Final Thoughts for Biomeds

You do not need to know every medical device before you can troubleshoot effectively.

You need a process.

Observe what is actually happening.

Isolate where the failure lives.

Test your theories with evidence.

Verify that the final repair actually solves the original problem.

Then document what you proved.

When you are staring at unfamiliar equipment and do not know where to start, return to the same four words:

Observe.

Isolate.

Test.

Verify.

The equipment may change.

The troubleshooting process usually does not.

— Jake

Important Note

Troubleshooting and return-to-service requirements vary by manufacturer, device type, failure mode, and facility policy. Follow current manufacturer service documentation, approved safety and performance testing procedures, appropriate test-equipment requirements, and your authorized service scope.

Related Biomed Basics

Back to Biomed Basics