On this page
Asset Type
Manufacturer
Model
What This Guide Helps With
Failed drug-library, firmware, or fleet deployments involving connectivity, device assignment, update readiness, server communication, configuration, or infrastructure problems.
Step-by-Step Troubleshooting
1. Protect Clinical Availability
Do not remove a functioning pump from active patient therapy merely to troubleshoot an update. Use another available device for testing when necessary and follow facility change-control procedures.
Expected outcome: Clinical operations continue while the update problem is evaluated safely.
2. Confirm the Update Type and Scope
Determine whether the failure involves a drug library, firmware package, configuration, or broader fleet deployment. Identify whether one pump, a group, or the entire fleet is affected.
Expected outcome: The problem is categorized as device-specific or system-wide, guiding the next checks.
3. Verify Device Identity and Assignment
Confirm the pump's asset identity, network identity, fleet assignment, and applicable device group using approved management tools. Check for mismatched or duplicate records.
Expected outcome: The device is assigned to the intended deployment group. If correcting the assignment allows deployment, verify completion and stop.
4. Check Basic Device Status
Confirm the pump is powered normally, not in active patient use, and in the appropriate operational state required for deployment according to approved procedures.
Expected outcome: The pump is available and ready to receive the update.
5. Verify Network Connectivity
Confirm that the device shows expected wireless/network connectivity. Check whether other network functions on the same pump are available and whether nearby fleet devices can communicate normally.
Expected outcome: The pump has network access. If restoring basic connectivity allows the update to deploy, troubleshooting can stop after verification.
6. Check for a Localized Infrastructure Problem
If multiple pumps in one area fail while pumps elsewhere succeed, compare wireless coverage, network location, access-point behavior, VLAN/network segmentation, and any recent infrastructure changes with the appropriate IT team.
Expected outcome: A local network issue is identified or ruled out.
7. Compare With a Known-Good Pump
Place the affected pump in a location where another Ivenix device has recently updated successfully, when practical.
Expected outcome: Successful deployment in the alternate location suggests an infrastructure issue. Continued failure on only one device suggests a device or management-record problem.
8. Verify Deployment Eligibility and Version Information
Using approved fleet-management tools, confirm the device is targeted for the intended package and that prerequisites or staged update requirements have not been missed. Do not manually force unsupported firmware or library versions.
Expected outcome: The device is eligible for the intended update and no obvious deployment prerequisite is missing.
9. Check Server or Fleet-Management Status
Determine whether the update service shows the pump as pending, offline, failed, completed, or otherwise unable to accept the package. Compare with other devices receiving the same deployment.
Expected outcome: The update service provides a consistent status that helps localize the problem.
10. Perform a Normal Restart if Permitted
With the pump out of patient use, perform a normal power cycle when appropriate. Do not enter unauthorized service menus or alter security/network configuration outside approved processes.
Expected outcome: The device reconnects and resumes communication with the fleet-management system. If the update then completes successfully, verify the installed version and stop.
11. Verify the Completed Deployment
After a successful update, confirm the expected drug library, firmware, or configuration version is shown through approved device or management-system information.
Expected outcome: The intended update is installed and the pump remains operational without new faults.
12. Escalate System-Level Failures
If multiple devices remain affected, involve the appropriate Clinical Engineering, pharmacy, IT/network, cybersecurity, or vendor support teams depending on whether the failure concerns the library, infrastructure, server, security, or firmware package.
Expected outcome: The issue is transferred to the correct service owner without unsafe local workarounds.
If the Problem Persists
Common external causes such as incorrect device assignment, unavailable network access, deployment readiness, localized wireless problems, and temporary communication failures have been ruled out. Remaining causes may include fleet-management infrastructure, certificates/security, server communication, device configuration, update-package compatibility, or a service-level software condition.
Remove an individual pump from service if the failed deployment leaves it with an unapproved, outdated, inconsistent, or otherwise unsuitable clinical configuration. Label it Out of Service when appropriate and evaluate it using approved Fresenius Kabi documentation and authorized management tools.
Do not manually alter firmware, drug-library files, security settings, or protected configuration outside approved procedures.
Knowing when to stop external troubleshooting is proper troubleshooting.
Clinical Use Tip
Before returning the pump to use after a library or firmware deployment, verify the actual installed version rather than relying only on the deployment console status.
Work Order Documentation (CCR Method)
CCR = Complaint, Cause, Resolution
Complaint
What was reported by the clinical staff.
Example:
"Pharmacy reported that one Ivenix pump remained pending while the current drug-library update deployed successfully to the rest of the unit."
Cause
What was observed during troubleshooting.
Example:
"Clinical Engineering found the pump was assigned to the wrong fleet-management device group."
Resolution
What action was taken.
Example:
"Corrected the approved fleet assignment, confirmed the library deployed successfully, verified the expected version on the pump, and returned the device to service."
Helpful Details to Include (If Known)
- Type of deployment
- Expected and observed version
- Number of affected pumps
- Device/fleet assignment
- Network connection status
- Location where failure occurred
- Known-good pump comparison
- Management-console status
- Recent network or server changes
- Restart result
- Final deployed version
- Final device status
Final Thought
Treat software deployment as a controlled clinical configuration process: verify device identity and connectivity first, distinguish device from infrastructure failures, confirm the actual installed version, and escalate rather than forcing unsupported changes.
That is successful troubleshooting.