On this page
Asset Type
Manufacturer
Model
What This Guide Helps With
Troubleshoots loss of PIC iX or network communication caused by cabling, ports, network infrastructure, monitor association, configuration, or communication-path failures.
Step-by-Step Troubleshooting
1. Protect the Patient and Maintain Alarm Surveillance
If the MX850 is not communicating with the Philips Information Center iX and central monitoring is required, provide an alternate verified monitoring and alarm-surveillance method before troubleshooting.
Do not assume bedside alarms are being received centrally while communication is impaired.
Expected outcome: Patient monitoring and alarm response remain continuously supported.
2. Confirm the Communication Failure
Determine whether:
- The bedside monitor has lost central communication
- The patient is absent from PIC iX
- Waveforms or numerics are missing centrally
- Alarm communication is affected
- Only one bedside monitor is affected
- Multiple monitors in the same area are affected
Record any network or communication indication shown on the MX850 or central station.
Expected outcome: The scope of the outage is identified.
3. Verify Bedside Monitor Operation
Confirm that the MX850 itself is functioning normally and displaying expected patient measurements and alarms locally.
Expected outcome: The problem is confirmed as a communication issue rather than a general monitor failure.
4. Inspect External Network Connections
Inspect accessible network connections, patch cables, wall ports, docking connections, or other approved external communication interfaces for:
- Loose seating
- Broken latches
- Visible cable damage
- Bent contacts
- Strain
- Accidental disconnection
Reseat normal external connections.
Expected outcome: The physical network connection is secure. If communication returns, continue to end-to-end verification.
5. Substitute a Known-Good Network Cable
When applicable and permitted by facility network policy, test using a known-good approved network cable.
Do not move devices between network segments or alter network addressing without authorization.
Expected outcome: Communication is restored if the original patch cable was defective.
6. Compare the Network Port or Location
If permitted, determine whether another known-good monitor communicates normally through the same infrastructure connection, or whether the affected MX850 communicates through another approved connection.
Coordinate with IT or clinical network support when needed.
Expected outcome: The failure is narrowed to the bedside monitor, cable, network port, or upstream infrastructure.
7. Verify Patient Association and Normal User-Level Configuration
Confirm that the monitor is associated with the expected bed, sector, or central monitoring workflow using approved operational controls.
Do not alter restricted network settings, addresses, VLANs, or protected configuration without authorization.
Expected outcome: The bedside device is associated with the intended central monitoring location.
8. Check for Broader Infrastructure Impact
Determine whether nearby monitors, central stations, switches, access points, servers, or related clinical systems are also affected.
A multi-device failure strongly suggests infrastructure or server-level involvement rather than multiple bedside monitor failures.
Expected outcome: Infrastructure incidents are recognized and escalated appropriately rather than misdiagnosed as individual device failures.
9. Verify the Complete Monitoring Path
After communication returns, confirm at the receiving PIC iX location:
- Correct patient/bed association
- Waveform transmission
- Numeric transmission
- Alarm receipt
- Alarm clearing or status updates
- Stable communication without repeated disconnects
Expected outcome: End-to-end bedside-to-central communication is fully restored. Troubleshooting can stop.
10. Escalate Persistent Communication Failure
If cabling, connections, approved configuration, and obvious local infrastructure causes are ruled out, involve the appropriate Philips support, clinical network, or hospital IT team.
Expected outcome: The unresolved communication failure is escalated to personnel authorized to evaluate network and system-level causes.
If the Problem Persists
Common bedside external causes have been ruled out. Remaining causes may involve network infrastructure, switch configuration, protected monitor network settings, PIC iX services, server communication, licensing or system configuration, or a service-level monitor interface fault.
The affected monitor should be removed from the central-monitoring workflow if required communication cannot be assured. When necessary, it should be:
- Removed from service
- Labeled Out of Service
- Sent for bench or network evaluation
- Evaluated using appropriate Philips documentation and approved network diagnostic methods
- Configured or repaired only by authorized qualified personnel
After corrective action, verify the complete bedside-to-central communication and alarm path before normal clinical use resumes.
Knowing when to stop external troubleshooting is proper troubleshooting.
Clinical Use Tip
Never assume restored network status alone is sufficient; verify that patient data and alarms actually arrive at the intended PIC iX central station.
Work Order Documentation (CCR Method)
CCR = Complaint, Cause, Resolution
Complaint
What was reported by the clinical staff.
Example:
"Clinical staff reported the Philips IntelliVue MX850 was monitoring locally but patient data was not appearing at the PIC iX central station."
Cause
What was observed during troubleshooting.
Example:
"Clinical Engineering found the bedside network patch cable had a damaged locking tab and was partially disconnected."
Resolution
What action was taken.
Example:
"Clinical Engineering replaced the approved network cable and verified stable waveform, numeric, and alarm communication at the assigned PIC iX central station."
Helpful Details to Include (If Known)
- Bedside location
- Central station or sector affected
- Exact communication indication
- Whether local monitoring remained normal
- Number of devices affected
- Cable and wall-port condition
- Known-good cable results
- Known-good port comparison
- Patient/bed association observed
- Central waveform and numeric verification
- Alarm transmission verification
- IT or network escalation details
- Final device status
Final Thought
Protect central alarm coverage first, verify the physical network path before changing configuration, distinguish isolated bedside failures from infrastructure outages, and confirm communication at the receiving station before closing the work order.
That is successful troubleshooting.