On this page
Asset Type
Manufacturer
Model
What This Guide Helps With
Use this guide when network communication, treatment-record transfer, or data export fails because of cabling, connectivity, configuration, destination, or infrastructure problems.
Step-by-Step Troubleshooting
1. Protect Clinical Workflow and Preserve Treatment Information
Determine whether the communication failure affects active patient care, documentation, treatment review, or another required workflow. Do not interrupt safe dialysis solely to troubleshoot a noncritical network issue.
Ensure clinical staff have an approved alternate documentation method if treatment data cannot transfer electronically.
Expected outcome: Patient care continues safely and required treatment information is not lost because of the communication problem.
2. Confirm the Exact Communication Failure
Determine whether the machine cannot connect to the network, cannot send a treatment record, cannot reach a destination system, fails only on export, or loses communication intermittently.
Record any displayed message and the affected destination or workflow.
Expected outcome: The problem is narrowed to network connection, application workflow, or data transfer.
3. Check the Physical Network Connection
Inspect the accessible network cable and connector for looseness, broken latches, damage, contamination, or disconnection.
Reseat the connection where appropriate and inspect the corresponding wall jack or approved network interface.
Expected outcome: The physical connection is secure. If communication returns after reseating or replacing a damaged cable, proceed to verification and stop troubleshooting.
4. Check Link and Network Status
Review normal user-accessible communication indicators or network status information without entering unauthorized service menus.
If accessible network hardware provides a normal link indication, confirm the connection appears active.
Expected outcome: Physical link presence is verified or the problem is localized to the network path.
5. Substitute a Known-Good Cable or Port
When facility policy permits, test with a known-good network cable or an approved network connection known to support the device.
Do not move the machine to an arbitrary jack or VLAN without coordinating with IT.
Expected outcome: A defective cable or local port is either identified or ruled out.
6. Compare With Other Devices
Determine whether other dialysis machines or systems in the same area can communicate normally with the same destination.
If multiple devices are failing simultaneously, suspect shared network, server, middleware, or interface infrastructure rather than multiple machine failures.
Expected outcome: The issue is localized to the individual machine or escalated as a shared infrastructure event.
7. Verify User-Accessible Configuration
Compare the machine's approved network or destination configuration with documented values or a known-good equivalent system where authorized.
Do not alter IP addressing, destination configuration, certificates, security parameters, or service settings without appropriate approval.
Expected outcome: No obvious configuration discrepancy is present, or an authorized correction restores communication.
8. Verify the Receiving System
Confirm the intended server, treatment-record system, interface, or export destination is available through the appropriate IT or application-support resource.
A machine may be functioning correctly while the destination system is unavailable.
Expected outcome: The receiving system is confirmed operational or the issue is appropriately reassigned to infrastructure support.
9. Test the Complete Data Path
After correction, perform an approved nonpatient communication or data-transfer test when available. Verify information reaches the intended destination and is associated with the correct machine or test record.
Expected outcome: Data passes through the complete communication path successfully. Troubleshooting can stop.
10. Perform Final Functional Verification
Verify communication remains stable and that no unrelated machine function was affected during troubleshooting. Confirm any temporarily used alternate clinical documentation process can be closed appropriately.
Expected outcome: Network and data-transfer functionality are restored and verified end to end.
If the Problem Persists
If the physical cable, jack, local connection, known-good substitutions, approved configuration, and destination availability have been verified, the remaining problem may involve internal communication hardware, software, network configuration, cybersecurity controls, middleware, server interfaces, or facility network infrastructure.
The device should be:
- Removed from network-dependent service when the failed function is required for safe or compliant clinical use.
- Labeled Out of Service if its required clinical workflow cannot be supported.
- Sent for repair or bench evaluation when a device-level communication fault is suspected.
- Evaluated using Fresenius Medical Care documentation and approved diagnostic tools.
- Coordinated with qualified IT, interface, cybersecurity, or application-support personnel when infrastructure is involved.
- Returned to service only after the complete required communication pathway has been verified.
Knowing when the problem has moved beyond the device and requires infrastructure escalation is proper troubleshooting.
Clinical Use Tip
A successful local network link does not prove treatment data reached its final destination; verify the complete communication path whenever the workflow depends on electronic transfer.
Work Order Documentation (CCR Method)
CCR = Complaint, Cause, Resolution
Complaint
What was reported by the clinical staff.
Example:
"Dialysis staff reported treatment records from the 5008S CorDiax were no longer reaching the clinical documentation system."
Cause
What was observed during troubleshooting.
Example:
"Clinical Engineering found the network cable latch was broken and the connector was intermittently losing link at the machine."
Resolution
What action was taken.
Example:
"The cable was replaced with a known-good approved cable, a test transfer reached the intended system successfully, and network communication was verified stable."
Helpful Details to Include (If Known)
- Exact communication or export failure.
- Displayed network message.
- Whether link is present.
- Network cable condition.
- Jack or port tested.
- Known-good cable or port result.
- Whether other machines are affected.
- Destination system involved.
- Configuration observed.
- End-to-end test result.
- Final device status.
Final Thought
Network troubleshooting should move from the physical connection outward through configuration and infrastructure, with patient care preserved and successful end-to-end data transfer verified before declaring the problem resolved.
That is successful troubleshooting.