Stryker InTouch

Network, Wi-Fi, or iBed Status Communication Failure

On this page

Asset Type

Hospital Bed

Manufacturer

Stryker

Model

InTouch

What This Guide Helps With

Troubleshooting missing network connection or iBed status caused by power, location, signal, cabling, configuration, infrastructure, or registration problems.

Step-by-Step Troubleshooting

1. Ensure Patient Safety and Preserve Clinical Workflow

Do not rely on remote bed-status, alarm, or location information that has not been verified.

Notify clinical staff and the responsible monitoring area that the bed’s network status may be unavailable. Use direct bedside observation and an alternate approved communication method until connectivity is restored.

Expected outcome: Patient care does not depend on missing or inaccurate remote bed information.

2. Confirm the Exact Communication Failure

Determine whether:

The bed shows no network or wireless connection.

The bed appears connected but is missing from the central application.

iBed status is delayed, incorrect, or stale.

Only one status parameter is missing.

The bed communicates in one room but not another.

The problem began after relocation, repair, software change, or network work.

Record visible network indicators and the bed’s displayed status without changing configuration.

Expected outcome: The problem is classified as local connection loss, central-system visibility failure, delayed status, or location-specific infrastructure failure.

3. Verify Basic Bed Operation and Power

Confirm that the bed is powered normally and completes startup without freezing, repeated rebooting, or abnormal communication messages.

Check AC and battery status. Network functions may be unreliable if the bed is repeatedly losing power or restarting.

Expected outcome: The bed remains powered and stable. Resolve power or startup issues before continuing network troubleshooting.

4. Verify the Bed’s Physical Location

Confirm that the bed is in the room, unit, or coverage area expected by the central system.

Ask whether the bed was recently moved, exchanged, stored, or returned from repair. Confirm that the clinical application is searching for the correct bed and location.

Expected outcome: The physical bed and expected electronic location match. If correcting a location assignment restores status, verify data updates and stop troubleshooting.

5. Inspect External Network Hardware

For a wired installation, inspect the network cable, wall jack, and bed connection for looseness, damage, contamination, or incorrect port use.

For a wireless installation, inspect externally visible antenna areas for damage and confirm that no accessory or equipment is obstructing or shielding the bed unnecessarily.

Do not connect the bed to an unapproved network port.

Expected outcome: External network connections are secure and undamaged, or the bed is positioned within the expected wireless coverage area.

6. Determine Whether the Problem Follows the Bed or Location

Move the bed to a known-good compatible location when operationally appropriate, or compare with another verified networked bed in the original room.

Coordinate testing with information technology or the responsible clinical systems team.

Expected outcome:

If the problem follows the bed, continue bed-side evaluation.

If the problem remains in the room or area, escalate the infrastructure, access point, switch port, or local network path.

If both work normally, investigate an intermittent coverage or connection issue.

7. Verify Network and iBed Indicators

Observe the bed’s available connection and status indicators.

Confirm whether the bed shows connected, disconnected, searching, or another general state. Do not invent or change network settings based only on assumptions.

Expected outcome: Indicator behavior is documented and consistent with the reported failure. If the connection restores, confirm that current bed status reaches the central system.

8. Verify Approved Configuration and Registration

Confirm through approved tools or with information technology that:

The bed is registered or assigned correctly.

The bed identifier matches the asset in the central system.

The intended network profile or facility configuration is present.

No recent replacement, database change, or system migration left the bed unassociated.

Do not alter security credentials, network profiles, or protected service settings without authorization.

Expected outcome: Bed identity and approved network configuration match the facility system. A corrected authorized assignment restores communication.

9. Check the Downstream Clinical Application

Confirm whether the central application, server, interface engine, or unit dashboard is operating for other beds.

Check for a broader outage, delayed updates, maintenance activity, or communication queue affecting multiple devices.

Expected outcome: The failure is isolated to the bed or identified as a system-wide infrastructure issue. Broad outages are escalated rather than treated as individual bed failures.

10. Verify Status From Bed to Central System

After correction, generate safe observable changes in normal bed status, such as brake or side-rail state, only when the bed is unoccupied or the action is clinically appropriate.

Confirm that the new status appears correctly at the receiving application without unacceptable delay.

Expected outcome: The complete communication path updates accurately and consistently. Troubleshooting can stop.

11. Escalate an Unresolved Communication Failure

Remove the bed from service when network communication is required for safe facility workflow and cannot be verified, or when the bed shows intermittent or inaccurate status that could mislead staff.

Otherwise, follow facility policy for temporary use with the network feature unavailable and clearly communicated.

Expected outcome: Staff do not unknowingly rely on incomplete or inaccurate remote bed information.

If the Problem Persists

Power, physical location, external connections, wireless coverage, bed identity, registration, approved configuration, and central-system availability have been evaluated. The remaining cause may involve an internal communication module, antenna, network interface, software, server integration, access point, switch, or facility configuration.

Remove the bed from service when required by facility policy, label it Out of Service, and coordinate bench evaluation with qualified Clinical Engineering and information technology personnel. Use appropriate Stryker and facility network documentation and approved test tools. Verify current status transmission through the complete clinical system before return to service.

Knowing when to stop external troubleshooting and escalate is proper troubleshooting.

Clinical Use Tip

Remote bed status is not a substitute for bedside verification when communication is delayed, missing, or inconsistent.

Work Order Documentation (CCR Method)

CCR = Complaint, Cause, Resolution

Complaint

What was reported by the clinical staff.

Example:
"Nursing reported that the InTouch bed was not appearing on the unit’s iBed status display after being moved to a new room."

Cause

What was observed during troubleshooting.

Example:
"Clinical Engineering found that the bed remained assigned to its previous room in the approved central-system configuration."

Resolution

What action was taken.

Example:
"The authorized system assignment was corrected, and Clinical Engineering verified that current brake and side-rail status updated at the receiving station."

Helpful Details to Include (If Known)

Final Thought

Protect clinical workflow, verify power, location, and infrastructure before assuming a bed failure, involve information technology appropriately, and document the complete end-to-end communication test.

That is successful troubleshooting.

Related Guides

Was this guide helpful?

Don't see a guide you need?

Suggest a Guide