On this page
Asset Type
Manufacturer
Model
What This Guide Helps With
Troubleshooting missing PIC iX waveforms, numerics, alarms, or patient association caused by network, docking, coverage, assignment, or central-system communication issues.
Step-by-Step Troubleshooting
1. Ensure Patient Safety First
Do not troubleshoot central-station communication while the IntelliVue X3 is the only device supporting an actively monitored patient.
- Notify clinical staff that remote monitoring and central alarm notification may be unavailable.
- Confirm that physiological monitoring and alarms remain functional locally on the X3.
- Maintain direct observation or transfer the patient to another verified monitor when central surveillance is clinically required.
- Do not assume that working bedside alarms guarantee that alarms are reaching PIC iX.
Expected outcome: Patient monitoring continues without relying on the failed central connection.
Continue Clinical Engineering troubleshooting only after alternate monitoring or observation has been established.
2. Confirm the Exact Communication Failure
Observe and document whether:
- The X3 displays a network-disconnected or central-monitoring message.
- The network indicator is absent, degraded, or changing intermittently.
- The patient is missing from PIC iX.
- The patient appears at PIC iX but waveforms, numerics, or alarms are not updating.
- PIC iX shows the wrong patient, bed, equipment label, or monitoring device.
- Communication fails only while the X3 is undocked or moving through certain areas.
- Other monitors assigned to the same central station are also affected.
Philips identifies the X3 as compatible with PIC iX and capable of sending waveforms, numerics, and alarms through a configured wired or wireless monitoring network.
Expected outcome: The failure is narrowed to the X3, its connection method, patient assignment, a specific location, or the wider PIC iX system.
3. Verify Local Monitoring Operation
Confirm that the X3:
- Powers on normally.
- Displays connected parameters and valid waveforms.
- Generates local visual and audible alarms during an approved functional test.
- Is not frozen, repeatedly restarting, or displaying unrelated system errors.
A monitor that is not collecting valid parameter data cannot transmit complete information to PIC iX.
Expected outcome: The X3 operates normally as a local patient monitor.
If local monitoring is also malfunctioning, stop and address the monitor or parameter failure separately.
4. Check Whether the Failure Is System-Wide
Inspect another known-good monitor connected to the same PIC iX clinical unit.
- If several monitors are missing or disconnected, suspect a network, PIC iX server, surveillance station, switch, or unit-wide infrastructure problem.
- If only one X3 is affected, continue troubleshooting the device, dock, connection, and assignment.
- Ask whether IT, monitoring support, or other departments are already responding to an outage.
Expected outcome: A facility-wide or unit-wide outage is separated from an individual-device problem.
If multiple devices are affected, escalate through the hospital’s approved PIC iX and clinical-network support process.
5. Verify Patient and Bed Assignment
Confirm at the X3 and PIC iX that:
- The correct patient is admitted or selected.
- The correct bed or equipment label is assigned.
- The X3 is associated with the intended clinical unit.
- The patient is not still assigned to another monitor or previous bed.
- A recent transport, discharge, transfer, or device exchange did not leave an outdated association.
Philips describes X3-to-PIC iX workflows as using patient assignment so that the patient’s waveforms, numerics, and alarms flow into the central platform.
Expected outcome: The X3, patient, bed, and PIC iX sector are correctly associated.
If correcting the assignment restores central monitoring, verify live data and alarm communication, document the correction, and stop.
6. Identify the Active Network Connection
Determine how the X3 is expected to communicate:
- Wired through a compatible IntelliVue Dock.
- Wired through a supported external power supply or network interface.
- Hospital 802.11 wireless network.
- Philips Smart-hopping or other facility-configured wireless monitoring infrastructure.
The X3 supports wired networking through compatible accessories and may use configured 802.11 or Philips wireless monitoring infrastructure, depending on the installed options and hospital design.
Expected outcome: Clinical Engineering knows which connection path should be carrying the data.
7. Check the Dock and Wired Connection
When the X3 is expected to communicate through a dock:
- Fully remove and reseat the X3.
- Inspect the dock and X3 contact areas for contamination, moisture, bent contacts, or physical damage.
- Confirm the dock is powered.
- Verify the network cable is fully seated at the dock and wall port.
- Inspect the cable for damaged clips, cuts, crushing, or excessive strain.
- Check for expected network-link indicators where visible.
- Test with a known-good approved network cable.
- Test the X3 in a known-good compatible dock and network location.
Expected outcome: The wired connection becomes stable and PIC iX begins receiving current data.
If another dock restores communication, remove the original dock or cable from service for evaluation.
8. Check Wireless Signal and Location Behavior
When the X3 communicates wirelessly:
- Confirm that wireless communication is enabled and the expected network indicator is present.
- Move the X3 to a location known to have reliable monitoring-network coverage.
- Observe whether communication returns or becomes stable.
- Compare performance with another known-good X3 in the same location.
- Ask whether the failure occurs only in hallways, elevators, stairwells, imaging areas, or during transport.
- Inspect the monitor externally for damage that may have followed a drop or impact.
Philips states that an appropriately configured X3 can monitor through areas covered by the hospital’s wireless network.
Expected outcome: A device-specific problem is distinguished from weak coverage, roaming difficulty, or a location-specific network issue.
Do not alter wireless security, VLAN, authentication, or network profiles without authorization.
9. Substitute Known-Good External Components
When permitted by hospital procedure:
- Test the affected X3 using a known-good dock, power supply, network cable, and network port.
- Test a known-good X3 using the original dock and connection.
- Change only one component at a time.
- Record which combination restores or reproduces the failure.
Expected outcome: The fault follows either the X3, an external accessory, or the network location.
If the failure follows an accessory, remove that accessory from service and replace or repair it.
10. Check for Duplicate, Stale, or Incorrect Equipment Association
Coordinate with the PIC iX or monitoring-system administrator to verify that:
- The X3 equipment label is unique.
- The device is registered in the correct clinical unit.
- A retired or replacement monitor is not using the same identity.
- The device is not still associated with another bed or patient.
- The correct sector is configured to receive the X3.
- No stale admission or equipment record is preventing reassignment.
Expected outcome: PIC iX recognizes the X3 as the correct, uniquely assigned monitoring device.
If correcting the central association restores communication, confirm live waveforms, numerics, and alarms before returning the device to service.
11. Perform a Controlled Restart
Only after the patient has been transferred or alternate monitoring is established:
- Disconnect the X3 from patient use.
- Shut it down using the normal procedure.
- Remove it from the dock or external connection.
- Wait briefly, then reconnect and restart it.
- Reconfirm the patient, bed, and equipment assignment.
- Observe whether network communication and PIC iX data return.
Expected outcome: A temporary software or communication-session problem clears and the X3 reconnects normally.
Do not repeatedly restart a monitor that continues to lose communication.
12. Verify End-to-End Operation
After communication returns:
- Confirm the correct patient and bed appear at PIC iX.
- Verify that waveforms and numerics update continuously.
- Generate an approved test condition or use the facility’s authorized alarm-verification process.
- Confirm the alarm appears locally and at the intended PIC iX sector.
- Observe the connection long enough to confirm that it remains stable.
- Repeat docking or transport testing when the original failure involved movement.
PIC iX is designed to display information received from networked monitors, including waveforms, numerics, and alarms.
Expected outcome: Bedside and central monitoring operate correctly with stable patient association and alarm communication.
If verification is successful, return the device to service and document the repair.
If the Problem Persists
If patient assignment, external connections, docks, cables, network ports, wireless coverage, and known-good substitutions have been checked, common external causes have been ruled out.
The remaining issue may involve:
- The X3 network interface or wireless hardware.
- Internal dock communication.
- Corrupted or incompatible device configuration.
- Network authentication or infrastructure configuration.
- PIC iX registration, server, or surveillance-system configuration.
- Software compatibility between the X3 and PIC iX environment.
The device should be:
- Removed from service.
- Labeled Out of Service.
- Sent for bench evaluation or authorized repair.
- Escalated to the Philips monitoring-system administrator, hospital IT network team, or Philips technical support as appropriate.
Do not change protected network settings, install software, or perform internal disassembly without the correct authorization, documentation, and service resources.
Knowing when external troubleshooting is complete and escalation is required is proper troubleshooting.
Clinical Use Tip
Never troubleshoot failed central-station communication on an active patient without alternate surveillance. Local bedside monitoring may continue even when PIC iX data and remote alarms are unavailable.
Move the patient to a verified backup monitoring device first whenever troubleshooting could interrupt monitoring, alarm notification, or therapy continuity.
Work Order Documentation (CCR Method)
CCR = Complaint, Cause, Resolution
Complaint
What was reported by the clinical staff.
Example:
"Clinical staff reported that the IntelliVue X3 displayed patient data locally but was not appearing at the assigned PIC iX central station."
Cause
What was observed during troubleshooting.
Example:
"The X3 communicated normally in a known-good dock, and testing found that the original dock’s network connection did not establish a stable link."
Resolution
What action was taken.
Example:
"Replaced the defective dock, verified the correct patient and bed assignment, and confirmed live waveforms, numerics, and alarm communication at PIC iX."
Helpful Details to Include (If Known)
- Local monitoring and alarms verified
- Exact network or central-monitoring message recorded
- Correct patient and bed assignment confirmed
- Wired, 802.11, or Smart-hopping connection identified
- Dock contacts inspected and reseated
- Network cable swapped
- Network port tested
- Known-good dock tested
- Known-good X3 comparison performed
- Wireless location or coverage behavior documented
- Other monitors checked for similar failure
- PIC iX equipment association reviewed
- Alarm communication verified at central station
- Accessories swapped during troubleshooting
- Power behavior during docking, undocking, and restart
- Environmental factors or location-specific behavior
- Network and connection indicator-light behavior
- Final device status documented
Final Thought
PIC iX communication failures require attention to both patient safety and the complete data path. Verify local monitoring first, then logically evaluate assignment, docking, cabling, wireless coverage, and central configuration. Escalate appropriately when the problem follows the X3 or affects the wider monitoring network, and clearly document the final status.
That is successful troubleshooting.