On this page
Asset Type
Manufacturer
Model
What This Guide Helps With
Failed interoperability involving patient association, orders, device assignment, network communication, interface services, auto-programming, or infusion documentation.
Step-by-Step Troubleshooting
1. Protect the Patient and Preserve the Clinical Workflow
Do not delay required therapy while troubleshooting interoperability. Clinical staff should use the facility-approved manual programming or documentation workflow when electronic integration is unavailable.
Expected outcome: Patient care continues safely without depending on the failed integration.
2. Confirm Which Direction Is Failing
Determine whether the problem involves an order not reaching the pump, auto-programming not populating expected values, pump data not documenting back to the EMR, or both directions.
Expected outcome: The failed portion of the integration path is clearly identified.
3. Verify the Correct Patient and Device Association
Confirm that the pump is associated with the intended patient, bed, location, or encounter according to facility workflow. Check for a stale or incorrect device association.
Expected outcome: The pump and patient context agree. If reassociation restores communication, verify both programming and documentation and stop.
4. Verify Network Connectivity
Confirm the pump has expected network connectivity and that other connected functions are available. Compare with another Ivenix pump in the same area.
Expected outcome: Basic pump network communication is operational.
5. Check the Clinical Workstation or EMR Session
Verify that the clinician is logged into the correct patient encounter and that the medication order is active and available through the normal workflow. Clinical Engineering should not modify medication orders.
Expected outcome: A valid order and patient context are present for testing.
6. Check Whether the Problem Is Device-Specific or Widespread
Ask whether other pumps, beds, units, or clinicians are experiencing the same problem.
Expected outcome: A single-device failure is separated from an interface, EMR, network, or enterprise-wide outage.
7. Verify Barcode and Identification Inputs if Used
If the workflow depends on scanning the patient, medication, clinician badge, or pump, confirm the expected identifiers can be read and accepted.
Expected outcome: Required workflow identifiers are captured successfully. If a scanner or barcode issue is corrected and integration resumes, troubleshooting can stop.
8. Compare With a Known-Good Pump
Using approved non-patient testing or a controlled test workflow, compare the affected pump with another known-good Ivenix device using the same location and network environment.
Expected outcome: The comparison determines whether the problem follows the pump or remains with the patient/location/interface workflow.
9. Check Integration-System Status
Work with IT or the integration team to verify the applicable interface engine, middleware, device gateway, and EMR connection are online and processing messages.
Expected outcome: The broader communication path is confirmed operational or the failure is localized to infrastructure.
10. Perform a Normal Pump Restart if Appropriate
With the pump removed from active patient use, perform a normal restart and allow the device to reconnect. Do not change protected network or interoperability configuration without authorization.
Expected outcome: The pump reconnects and resumes the expected integration workflow.
11. Verify Both Directions of Communication
After corrective action, verify that the intended programming information reaches the pump accurately and that completed infusion information is documented back to the correct patient record when applicable.
Expected outcome: The complete integration path functions correctly. Troubleshooting can stop.
12. Escalate Persistent Interface Problems
If communication remains unreliable, engage the appropriate Clinical Engineering integration specialist, IT/network team, EMR/interface team, or Fresenius Kabi support.
Expected outcome: The unresolved issue is escalated with enough information to trace the complete workflow.
If the Problem Persists
External causes such as incorrect patient association, lost network connectivity, barcode workflow problems, incorrect encounter context, and simple device-specific communication issues have been ruled out. Remaining categories include interoperability middleware, interface-engine routing, network services, certificates, EMR configuration, device configuration, or vendor-level software.
Remove the pump from service if integration reliability is required for its intended clinical use and cannot be assured. Label it Out of Service and evaluate it using approved documentation and qualified personnel.
Do not modify protected interoperability settings or medication configuration as an unapproved troubleshooting shortcut.
Knowing when to stop external troubleshooting is proper troubleshooting.
Clinical Use Tip
When auto-programming or auto-documentation is unavailable, ensure clinical staff know which approved manual workflow is being used so therapy and documentation remain complete.
Work Order Documentation (CCR Method)
CCR = Complaint, Cause, Resolution
Complaint
What was reported by the clinical staff.
Example:
"Nursing reported that infusion orders appeared in the EMR but would not populate on one Ivenix pump."
Cause
What was observed during troubleshooting.
Example:
"Clinical Engineering found the pump was associated with the previous patient's encounter after being moved between rooms."
Resolution
What action was taken.
Example:
"Corrected the approved device-to-patient association, verified successful auto-programming and documentation with the correct encounter, and returned the pump to service."
Helpful Details to Include (If Known)
- Auto-programming or documentation direction affected
- Patient/device association status
- Room or bed location
- Network connection status
- Barcode workflow results
- Other devices affected
- Known-good pump comparison
- Interface or middleware status
- Restart result
- Successful programming verification
- Successful documentation verification
- Final device status
Final Thought
Troubleshoot the entire communication path rather than the pump alone, preserve safe manual clinical workflows during outages, verify patient identity carefully, and escalate system-level failures with clear documentation.
That is successful troubleshooting.