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 connections, infrastructure, configuration, or external systems.
Step-by-Step Troubleshooting
1. Protect the Patient and Preserve Treatment Continuity
Determine whether the communication failure affects dialysis therapy itself or only documentation and data transfer.
Do not interrupt safe treatment solely to troubleshoot a nonessential network problem unless required by clinical policy. If communication is required for safe care, provide an approved alternate documentation or workflow method.
Expected outcome: Patient care continues safely while the communication problem is evaluated.
2. Confirm the Exact Communication Failure
Determine whether the issue involves:
- No network connection
- Missing treatment record
- Failed data export
- Intermittent transfer
- Incorrect patient association
- Failure to communicate with an external system
- Failure affecting one machine or multiple machines
Record any displayed network or export message exactly.
Expected outcome: The affected communication path and scope are identified.
3. Verify the Physical Network Connection
Inspect accessible network cabling and connectors for:
- Loose connection
- Damaged latch
- Bent or damaged connector
- Crushed cable
- Disconnected wall jack
- Cable routed under equipment or furniture
If permitted, reseat the connection.
Expected outcome: The physical communication connection is secure and visibly intact.
4. Check Link or Connection Status
Observe available normal network or communication indicators without entering unauthorized service menus.
Compare the affected machine with another working SURDIAL X or nearby supported device when practical.
Expected outcome: A physical network connection is present, or the absence of one identifies the next troubleshooting direction.
5. Test the External Network Path
Use an approved known-good network cable or known-good active connection point when facility policy allows.
Coordinate with IT before moving the device to a different network segment or making infrastructure changes.
Expected outcome: A failed external cable or port is either isolated or ruled out.
6. Determine Whether the Problem Is Device-Specific
Check whether:
- Other dialysis machines can communicate
- The receiving application is operational
- The issue is limited to one room or switch
- Multiple devices lost connectivity simultaneously
- Recent network maintenance occurred
Do not change network settings simply because the device is offline.
Expected outcome: The problem is classified as device-specific, infrastructure-related, or receiving-system related.
7. Verify Approved Network Configuration
Compare the affected machine's approved network configuration with documented facility records or a known-good equivalent device.
Check items such as assigned network identity and communication settings only within authorized access levels.
Do not alter addresses, interface parameters, or application settings without coordination with the responsible IT or integration team.
Expected outcome: The machine's approved configuration is confirmed or an authorized configuration discrepancy is identified.
8. Verify the Treatment Record or Export Destination
Confirm the intended external destination is available and that the correct workflow is being used.
Determine whether the issue is:
- Record not created
- Record created but not transmitted
- Record transmitted but not received
- Export destination unavailable
- Patient association mismatch
Preserve existing treatment information and avoid unnecessary deletion or recreation of records.
Expected outcome: The failure point between the machine and receiving system is narrowed down.
9. Perform an Approved Communication Test
After correcting any cable, port, or authorized configuration issue, perform a controlled test transaction or data export according to facility procedure.
Verify receipt at the intended destination rather than relying only on a local "sent" indication.
Expected outcome: Data passes through the complete communication path and is confirmed at the receiving system. Troubleshooting can stop.
10. Perform Final Functional Verification
Confirm:
- Network connection remains stable
- A test record or approved data transfer succeeds
- The receiving system receives the information correctly
- No unintended patient association or duplicate record was created
- Dialysis functions remain unaffected
Expected outcome: The complete network and data-transfer path is verified and the machine may be returned to normal clinical workflow.
If the Problem Persists
If the physical cable, connection point, external network path, receiving system, and approved device configuration have been checked but communication still fails, common external causes have been ruled out.
Possible remaining categories include device network hardware, interface software, middleware, server configuration, application mapping, cybersecurity controls, or infrastructure routing.
If reliable data communication is required for safe clinical operation, the device should be:
- Removed from service when required by facility policy
- Labeled Out of Service if unavailable for clinical use
- Sent for repair or bench evaluation when a device fault is suspected
- Evaluated using appropriate Nipro documentation and approved test equipment
- Configured or repaired only by qualified Clinical Engineering, IT, integration, or vendor personnel
Verify the complete end-to-end communication path before closing the issue. Knowing when to stop device-level troubleshooting and escalate to the appropriate support team is proper troubleshooting.
Clinical Use Tip
A successful local export does not prove integration is working; confirm the treatment data arrives correctly at the intended receiving system.
Work Order Documentation (CCR Method)
CCR = Complaint, Cause, Resolution
Complaint
What was reported by the clinical staff.
Example:
"Dialysis staff reported treatment records from one SURDIAL X were no longer reaching the receiving system."
Cause
What was observed during troubleshooting.
Example:
"Clinical Engineering found the network cable at the machine had a damaged retaining tab and was intermittently disconnecting."
Resolution
What action was taken.
Example:
"Clinical Engineering replaced the damaged cable, verified stable network connectivity and successful end-to-end treatment-record transfer, and returned the machine to service."
Helpful Details to Include (If Known)
- Exact network or export message
- Whether one or multiple machines were affected
- Network cable condition
- Link or communication indicator state
- Known-good cable or port test
- Recent network or server changes
- Approved configuration observed
- Receiving system status
- Test record or export result
- Final machine status
Final Thought
Start with the physical connection and determine whether the failure belongs to the device, network, or receiving application before changing configuration. Preserve clinical records, escalate to the appropriate team when needed, and document successful end-to-end verification.
That is successful troubleshooting.