How to Troubleshoot Communication Failures

A practical way to find where communication stops between a medical device, accessory, network, server, or connected system

Communication failures are some of the easiest problems to overcomplicate.

Published August 14, 2026 · Revised September 5, 2026

Back to Biomed Basics

What This Page Explains

This page covers:

The Simple Version

Communication is a chain with a source, a physical or wireless link, one or more interfaces, a transport path, and a destination that must recognize and accept the data. When information does not arrive, the most useful question is: How far did it get? Finding the last confirmed good point turns a vague communication complaint into a smaller, testable problem.

Be exact about the symptom before changing anything. “The monitor displays ECG locally but the central station shows the bed offline” identifies different working and failed points. “It doesn't communicate” does not. Also establish whether the failure affects one device, one room, one unit, one application, or an entire site; the size of the failure often identifies the size of the shared component.

Worked Example: Find the Last Known-Good Point

An ECG cart completes an acquisition but the study does not appear in the management system. First confirm that the study exists on the cart and note whether it is queued, rejected, or marked as sent. Then verify the cart's link or Wi-Fi association, network configuration, destination settings, time, and patient identifiers. A successful ping, when permitted, proves only that some network traffic can pass; it does not prove the required service, port, authentication, route, or application is working.

If another cart on the same network can send to the same destination, compare the two configurations without copying values blindly. If no carts can send, preserve timestamps and error messages and investigate the shared network, interface engine, server, or application. Avoid factory resets and broad configuration changes early in the process: they erase evidence and can turn one known problem into several unknown ones.

Start With the Exact Failure

Do not troubleshoot:

Communication problem.

Be specific.

Examples:

Each failure occurs at a different point in the path.

What Is Supposed to Communicate With What?

Before troubleshooting, define the endpoints.

Examples:

SpO2 Module → Patient Monitor

Patient Monitor → Central Station

ECG Cart → MUSE

Monitor → Integration Server → EMR

Bed → Nurse Call

Different paths require different tests.

Draw the Path

It does not need to be a fancy diagram.

Example:

Monitor

↓

Ethernet Cable

↓

Wall Jack

↓

Switch

↓

Network

↓

Central Monitoring Server

↓

Central Station

Now you have places to test.

Start at the Simplest Layer

Communication often begins with something physical.

Check:

Do not begin with firewall rules when the Ethernet cable is unplugged.

Device-to-Accessory Communication

Not all communication uses a network.

A device may communicate directly with:

If the accessory is:

Not Recognized

consider:

Known-Good Accessory Test

Suspect module:

Not recognized.

Known-good module:

Works.

Suspect module on another device:

Still not recognized.

The failure follows the module.

That is strong isolation.

If Multiple Accessories Fail

Suppose three known-good modules all fail in one device.

Those same modules work in another device.

The problem likely stays with:

Do not replace all three modules.

Physical Link First

For wired network communication, check whether a physical link exists.

Ethernet ports often have link/activity indicators.

If there is no link:

Look at:

Do not start troubleshooting DNS.

Link Light Does Not Mean Everything Works

A link light generally proves:

The physical Ethernet connection negotiated at some level.

It does not prove:

It only clears one part of the path.

Cable Swap

If communication is wired, try a known-good compatible cable.

If the problem disappears, cross-test the original cable when practical.

Make the failure follow something.

Location Swap

If a networked device fails in one room, move it to a known-good location.

Then place a known-good device in the suspect location.

This helps separate:

Example:

Device A fails in Room 5.

Device A works in Room 6.

Device B also fails in Room 5.

That strongly points toward Room 5 infrastructure.

IP Address

Once physical link is good, check network configuration.

A typical networked medical device may need:

One incorrect setting may prevent communication.

Duplicate IP Address

Two devices using the same IP can create strange intermittent communication problems.

Symptoms may include:

If the problem began after device replacement or configuration changes, consider duplicate addressing.

Subnet

The subnet helps determine which addresses are considered local.

A wrong subnet mask can allow some communication while breaking other paths.

Do not assume:

It has an IP address.

means network configuration is correct.

Default Gateway

The gateway allows the device to reach destinations outside its local network.

A device may communicate locally but fail to reach a remote server if the gateway is wrong.

DNS

DNS translates names into IP addresses.

A device may be configured to connect to:

server.hospital.local

instead of a numeric IP.

If DNS fails, the network itself may still be healthy.

Ping

Ping can be useful.

But it is often misunderstood.

If a device can ping a server, you have proven some level of IP communication.

You have not proven the actual application works.

A device can ping and still fail because of:

Cannot Ping Does Not Automatically Mean Network Failure

Some systems intentionally block ping.

Do not use ping as the only network test.

Know what the system is expected to support.

Ports

Applications often communicate through specific network ports.

Example:

The device can reach the server IP.

But the required application port is blocked.

Result:

Network appears alive.

Application does not work.

That is why:

It pings.

does not end troubleshooting.

Firewalls

Firewalls may allow some traffic and block other traffic.

If communication stops after:

check whether the required communication path is permitted.

Coordinate with IT when appropriate.

Wi-Fi

Wireless communication adds another layer.

Possible problems include:

Location becomes especially important.

Wi-Fi Location Pattern

Device works in ICU rooms.

Drops in hallway.

Known-good device behaves the same way.

That points toward:

not necessarily a bad Wi-Fi radio.

Authentication

Wireless devices may require:

A device can see the wireless network and still fail to join it.

That is different from weak signal.

Serial Communication

Older and specialized medical equipment may use serial communication such as RS-232.

Check:

Both sides must generally agree on the communication settings.

Serial Example

Device and server physically connected.

No data received.

Device:

9600 baud.

Interface:

115200 baud.

Hardware may be completely fine.

The configuration does not match.

USB Communication

USB problems may involve:

Try:

Do not assume a physically intact USB connector means the device is recognized correctly.

USB Power vs USB Data

A USB accessory may receive power but still fail to communicate.

That means:

The light comes on.

does not prove the data path works.

Network Interface vs Application

A device may show:

Network Connected

while the clinical workflow still fails.

Example:

Monitor has Ethernet link.

IP configuration correct.

But central station does not display it.

Now the failure is likely farther downstream.

Find the Last Known-Good Point

This is one of the best methods for any communication problem.

Example:

Monitor displays patient data correctly.

Gateway receives the data.

Interface engine receives the message.

EMR does not display it.

The problem is somewhere after the interface engine.

Do not troubleshoot the bedside monitor anymore.

Work Forward From the Source

Ask:

Does the source generate the expected information?

Example:

ECG cart has an ECG stored locally.

Good.

Next:

Did it enter the transmission queue?

Good.

Next:

Did it leave the cart?

Continue forward.

Work Backward From the Destination

You can also start from the receiving side.

Example:

Central station has no monitor.

Does the server see the device?

No.

Does the network see the device?

Yes.

Now you narrowed the failure between device network communication and server registration.

Central Monitoring

A bedside monitor missing from central could involve:

First verify the monitor itself is functioning locally.

Then trace communication outward.

Monitor Works Locally

If the bedside monitor:

but central monitoring is missing, the patient-monitoring hardware may be fine.

Focus on communication.

Patient Association

Some systems require:

The network connection can be perfect while data appears in the wrong location or not where staff expect it.

That is a configuration/workflow failure.

EMR Integration

Medical device data often travels through several systems.

Example:

Monitor

↓

Gateway

↓

Integration Server

↓

Interface Engine

↓

EMR

Do not call the whole thing:

An EMR problem.

Find where the data stops.

Device Data Present Locally

Suppose blood pressure appears correctly on the monitor.

That proves the measurement exists at the source.

Next ask:

Does the gateway receive it?

If yes, move downstream.

Message Queues

Some systems queue data when communication is unavailable.

Examples:

A growing queue can tell you:

The source is creating data.

But transmission is failing.

That is useful isolation.

MUSE Example

ECG acquired successfully.

Stored locally.

Transmission queue shows pending ECGs.

Network link good.

Now investigate:

Do not troubleshoot ECG acquisition.

Nurse Call Communication

Not every communication system sends digital packets.

Nurse call may use:

The same isolation principle still works.

Find where the signal stops.

Communication Logs

Logs may show:

These are valuable clues.

Exact Error Matters

Write down:

Example:

Server Connection Timeout

is different from:

Network Cable Disconnected.

The first suggests the physical link may still exist.

The second points lower in the communication path.

Timeout

A timeout generally means the device expected a response and did not receive one in time.

Possible causes include:

Do not automatically replace the device interface.

Connection Refused

This can suggest the destination responded but the requested service was unavailable or rejected.

That is different from:

No network.

Again, exact errors matter.

Authentication Failure

If the log says:

Authentication Failed

communication may already be reaching the destination.

Now investigate:

That is much farther along the path than a bad Ethernet cable.

Certificates

Secure communication may depend on certificates.

Problems may involve:

The network can be perfectly healthy while secure application communication fails.

Date and Time

Incorrect device time can affect secure communication and log interpretation.

Check:

when certificates or event correlation are involved.

Software Version

Communication compatibility may depend on software or firmware.

A new module or server may require a specific version.

If communication stopped after an upgrade, check compatibility.

Restarting

A reboot may temporarily restore communication.

That can be useful evidence.

But it is not necessarily the repair.

If a device repeatedly loses communication until rebooted, investigate:

Server Problems

If many devices simultaneously lose the same connection, look upstream.

Examples:

One hundred devices probably did not develop bad network boards at once.

Common-Point Thinking

Ask:

What do all the failing devices share?

Possibilities:

This is especially powerful in large systems.

One Device vs Many Devices

One device fails:

Device-specific problem becomes more likely.

One entire unit fails:

Look for shared infrastructure.

Whole hospital fails:

Look much farther upstream.

The scale of the failure is a clue.

Compare With Known-Good Equipment

If Device A fails:

Try known-good Device B in the same setup.

Then try Device A in a known-good setup.

This is one of the fastest ways to separate:

Do Not Change Everything at Once

Avoid simultaneously:

If communication returns, you will not know why.

Change one variable when practical.

Document Network Settings Before Changing Them

Record:

before editing configuration.

Otherwise you may lose the original evidence.

Real-World Example: Monitor Missing From Central

Monitor locally:

Normal.

Ethernet link:

Good.

Known-good cable:

No change.

Monitor works at another network jack.

Known-good monitor fails at original jack.

Failure stays with room infrastructure.

No reason to replace the monitor network board.

Real-World Example: Device Can Ping but Application Fails

Device:

Pings server.

Application:

Cannot connect.

Logs:

Connection refused on required service.

Now investigate the application/service/port instead of physical networking.

Real-World Example: Module Not Recognized

Original module:

Not recognized.

Known-good module:

Also not recognized.

Both modules work in another device.

Failure stays with host device.

Focus on:

Real-World Example: ECG Not Reaching MUSE

ECG acquired.

Stored locally.

Queue shows unsent exams.

Network link present.

Another cart on same network transmits normally.

Now focus on:

The acquisition system is working.

Real-World Example: Wi-Fi Drops in Hallway

Monitor works in patient rooms.

Disconnects repeatedly in one corridor.

Known-good monitor does same thing.

Pattern follows the location.

Investigate wireless coverage or roaming.

Real-World Example: Data Missing From EMR

Monitor displays measurement.

Integration gateway receives it.

Interface engine shows message sent successfully.

EMR does not display it.

Do not keep troubleshooting the bedside monitor.

You have already proven the data traveled through several layers.

Common Mistakes

Blaming the Network Immediately

Check the physical path and device first.

Replacing Communication Hardware Because “It Won't Connect”

Prove where communication stops.

Assuming a Link Light Means Everything Works

It only proves part of the path.

Assuming Ping Proves the Application Works

It does not.

Ignoring Configuration

Communication depends heavily on settings.

Troubleshooting the Device After Data Already Left It

Move downstream.

Changing Several Network Settings at Once

Preserve isolation.

Blaming Another Department Without Evidence

Find the failure boundary first.

A Useful Troubleshooting Framework

Ask:

Who is sending?

Then:

Who is receiving?

Then:

What path connects them?

Then:

What is the last point where communication is known to work?

Then:

What is the next point where it fails?

The fault is usually somewhere between those last two answers.

Another Useful Question

Ask:

Is this a physical connection problem, a network path problem, or an application/configuration problem?

Those categories can dramatically narrow the search.

What Did You Actually Prove?

If an Ethernet link light is on, you proved:

The physical Ethernet link is active under those conditions.

You did not prove:

If data appears correctly at the integration server, you proved much more:

The device successfully transmitted the data to that point.

Keep moving through the path until you find where it stops.

Final Thoughts for Biomeds

Communication failures become confusing when you treat the entire system as one giant black box.

Break it apart.

Source.

Cable.

Port.

Network.

Server.

Application.

Destination.

Then ask:

Where was the last place communication definitely worked?

Do not troubleshoot downstream systems before proving the source.

Do not replace device hardware after proving the data already left the device.

Do not blame the network because the screen says:

Communication Error.

Follow the path.

Test one section at a time.

Use known-good devices and locations.

Check the logs.

Compare configuration.

Find where the signal stops.

Once you identify that boundary, even a complicated communication failure becomes much easier to understand.

— Jake

Important Note

Medical device communication may involve clinical networks, cybersecurity controls, servers, integration platforms, and other systems outside normal biomed service scope. Follow current manufacturer documentation, facility cybersecurity and change-control procedures, approved network practices, and coordinate with IT, clinical informatics, or other responsible teams when troubleshooting extends beyond the medical device.

Related Biomed Basics

Back to Biomed Basics