On this page
Asset Type
Manufacturer
Model
What This Guide Helps With
Troubleshoots loss of network or IntelliSpace Perinatal communication through external connections, network availability, configuration, ports, infrastructure, and endpoint isolation.
Step-by-Step Troubleshooting
1. Protect the Patient and Establish an Alternate Monitoring Workflow
A local fetal monitor may continue displaying patient data even when network communication is unavailable, but remote surveillance, charting, or data distribution may be affected.
Notify clinical staff of the communication loss and establish the approved alternate monitoring and documentation process before troubleshooting.
Expected outcome: Clinical staff are not relying on an unavailable central or networked monitoring path.
2. Confirm the Scope of the Failure
Determine whether:
- One Avalon FM50 is affected
- Multiple monitors are affected
- One room or network jack is affected
- IntelliSpace Perinatal is unavailable broadly
- Local monitoring is normal but remote data is missing
- Communication is intermittent
Confirm the destination or system that is not receiving data.
Expected outcome: The issue is classified as device-specific, room-specific, or system-wide.
3. Verify Local Monitor Operation
Confirm the FM50 is operating normally at the bedside and displaying expected monitoring information.
If the monitor itself is unstable, restarting, or losing parameters, resolve the local equipment issue separately before treating the problem as network-only.
Expected outcome: The monitor functions normally aside from communication.
4. Inspect External Network Connections
Inspect accessible network and communication cables for:
- Loose connections
- Damaged connectors
- Broken locking tabs
- Pinched or cut cables
- Disconnected patching
- Incorrectly connected external adapters
Reseat connections at the monitor and accessible wall or approved interface points.
Expected outcome: All external communication connections are secure and physically intact.
5. Check Available Link or Communication Indicators
Observe any normal accessible link, communication, or connection indicators on the monitor, network adapter, or approved external interface.
Do not interpret an indicator beyond what is supported by local documentation, but use it to compare the affected setup with a known-working setup.
Expected outcome: Physical network connectivity appears comparable to a functioning station.
6. Substitute a Known-Good External Network Cable
Replace the accessible device-side network cable with a known-good cable.
Do not disturb permanent facility cabling beyond approved Clinical Engineering scope.
Expected outcome: Communication is restored if the original patch cable was defective.
If communication remains stable after cable replacement, complete end-to-end verification and stop troubleshooting.
7. Compare the Network Location
When operationally appropriate, test the affected monitor on a known-working approved network connection, or test a known-good compatible monitor at the affected location.
Coordinate moves and network testing with clinical operations and facility policy.
Expected outcome: The problem follows either the monitor or the room/network location.
8. Verify Authorized Network Configuration
Review the monitor's authorized network configuration and compare it with current site records or a known-good equivalent unit.
Do not change IP addressing, VLAN-related configuration, destination settings, or other network parameters without authorization and validated site information.
Expected outcome: Device configuration matches the intended network environment.
9. Confirm the Complete IntelliSpace Perinatal Path
Verify whether the device appears at the expected receiving system or workstation and whether data from other monitors is arriving normally.
Coordinate with the responsible perinatal application or network support team when the failure extends beyond the bedside connection.
Expected outcome: The fault is isolated to the FM50, network infrastructure, or receiving application.
10. Perform End-to-End Functional Verification
After correcting the identified issue, verify:
- Bedside monitoring remains normal
- Network connection remains stable
- The expected receiving system sees the correct monitor
- Patient or test data is transmitted through the intended path
- No repeated disconnect occurs during the verification period
Use test data or an approved nonpatient verification method whenever practical.
Expected outcome: Communication from the Avalon FM50 through the intended network path is restored and stable.
If successful, troubleshooting can stop.
11. Escalate Unresolved Communication Failure
If the monitor works on one network location but not another, escalate the affected port, cabling, switch, VLAN, or infrastructure path to the appropriate network team.
If the failure follows the FM50 across known-good connections, remove the monitor from service when network integration is required and route it for service evaluation.
Expected outcome: Responsibility is transferred to the correct technical group with the problem clearly isolated.
If the Problem Persists
External connections, patch cables, location comparison, local monitor operation, and authorized configuration have been checked.
Persistent communication failure may involve the monitor's communication interface, hospital network infrastructure, network configuration, IntelliSpace Perinatal services, or another integration-level condition.
The device should be:
- Removed from service when reliable network communication is required for its clinical role
- Labeled Out of Service when appropriate
- Sent for repair or bench evaluation if the fault follows the monitor
- Evaluated using appropriate Philips documentation and approved test equipment
- Configured or repaired only by qualified personnel
Infrastructure or application failures should be escalated to the appropriate hospital network or IntelliSpace Perinatal support team.
Complete end-to-end communication verification before return to service.
Knowing when to stop external troubleshooting and escalate is proper troubleshooting.
Clinical Use Tip
Verify the complete monitoring path at the receiving station; a normal bedside display does not confirm that remote fetal monitoring or documentation is functioning.
Work Order Documentation (CCR Method)
CCR = Complaint, Cause, Resolution
Complaint
What was reported by the clinical staff.
Example:
"Labor and delivery staff reported that one Avalon FM50 displayed normally at the bedside but was no longer communicating with IntelliSpace Perinatal."
Cause
What was observed during troubleshooting.
Example:
"Clinical Engineering found a defective external network patch cable, while the monitor communicated normally after connection with a known-good cable."
Resolution
What action was taken.
Example:
"Replaced the patch cable and verified stable bedside operation and successful end-to-end communication with the intended IntelliSpace Perinatal destination."
Helpful Details to Include (If Known)
- Whether local monitoring remained normal
- Number of monitors affected
- Room and network location
- External cable condition
- Link or communication indications
- Known-good cable result
- Known-good network location result
- Configuration comparison
- Receiving-system behavior
- Teams notified
- Final end-to-end verification
Final Thought
Network troubleshooting should follow the entire communication path from the bedside monitor through external cabling and infrastructure to the receiving application. Preserve clinical monitoring, isolate the affected segment logically, avoid unauthorized network changes, and document the final end-to-end verification.
That is successful troubleshooting.