On this page
Asset Type
Manufacturer
Model
What This Guide Helps With
Troubleshoot network connectivity, data export, and approved software-update failures involving cables, ports, configuration, media, infrastructure, and external systems.
Step-by-Step Troubleshooting
1. Protect Clinical Operation Before Troubleshooting Connectivity
Determine whether the communication failure affects only data handling or also impacts clinical monitoring, alarm routing, documentation, or workflow. If any safety-related remote function is unavailable, provide an alternate monitoring or communication method.
Do not interrupt ventilation simply to troubleshoot nonessential connectivity.
Expected outcome: Patient care continues safely and any lost secondary communication path has an appropriate backup.
2. Confirm the Exact Communication or Update Failure
Determine whether the issue involves loss of network connection, inability to export data, missing data at another system, an unrecognized approved storage device, or failure of an authorized software-update process.
Record displayed messages and the last known successful operation.
Expected outcome: The failure point is narrowed to network connectivity, data transfer, external media, receiving-system workflow, or update processing.
3. Verify Physical Network Connections
For wired connectivity, inspect the external network cable and connector for loose seating, broken latch tabs, contamination, visible damage, or excessive strain. Confirm the cable is connected to the intended network port.
Use a known-good approved cable when appropriate.
Expected outcome: The physical network connection is secure and undamaged. If cable replacement restores communication, verify end-to-end data flow and stop troubleshooting.
4. Verify the Infrastructure Port
Confirm the network wall jack or switch-connected infrastructure path is active using appropriate facility IT or Clinical Engineering methods. Compare with a known working connection when authorized.
Do not change switch, VLAN, firewall, or enterprise network settings without the appropriate IT process.
Expected outcome: The infrastructure port is available and assigned for the intended device use. If the port is inactive or incorrectly provisioned, escalate to IT rather than modifying the ventilator unnecessarily.
5. Review Authorized Network Configuration
Compare accessible network configuration with documented facility records. Check relevant addressing and destination information only within the technician's authorized scope.
Do not change network settings merely as a trial when the correct configuration is unknown.
Expected outcome: Device configuration agrees with approved network documentation. If a documented configuration discrepancy is corrected by authorized personnel and communication returns, proceed to end-to-end verification.
6. Isolate the Ventilator From the Receiving System
Determine whether the ventilator shows a valid network connection while the destination system fails to receive data. Coordinate with IT, clinical informatics, or the integration-system owner to determine whether the receiving application, interface, server, or network path is available.
Expected outcome: The fault domain is narrowed to the ventilator, network infrastructure, interface, or destination system rather than assuming the ventilator is defective.
7. Check Data Export Media and External Connections
For approved local export, inspect the storage device or external connection for damage, incorrect seating, unsupported use, insufficient accessibility, or other obvious external problems.
Use only approved media and follow facility cybersecurity requirements.
Expected outcome: The approved export medium is recognized and usable. If replacing defective external media restores export, verify the exported data before closing the work order.
8. Verify Software-Update Prerequisites
For an authorized software update, confirm that the update package, media, device identification, power conditions, and documented prerequisites match the approved manufacturer and facility process.
Do not download unofficial software, alter packages, or force an interrupted or incompatible update.
Expected outcome: All approved prerequisites are present. If they are not, stop the update and obtain the correct package or support rather than improvising.
9. Verify End-to-End Communication After Correction
Confirm network status and verify that actual test data or approved test communication reaches the intended destination. For local export, confirm the expected information is successfully written and accessible. After an approved software update, verify the ventilator starts normally and required configuration and functional checks pass.
Expected outcome: The complete communication or update workflow functions from the ventilator through the intended endpoint. If confirmed, troubleshooting can stop.
10. Escalate Unresolved Connectivity or Update Problems
If cables, ports, configuration, external media, and destination-system availability have been checked but the issue remains, do not perform unauthorized software recovery, internal network-module repair, or undocumented configuration changes.
Expected outcome: The unresolved issue is escalated to the appropriate Vyaire service, IT, cybersecurity, interface, or Clinical Engineering support path.
If the Problem Persists
Common external cable, network-port, infrastructure, destination-system, configuration, and export-media causes have been ruled out. The remaining issue may involve device software, an internal communication interface, network configuration requiring higher authorization, integration infrastructure, compatibility, or a service-level software condition.
The ventilator should be handled according to the clinical impact. If the communication or software problem affects safe operation, alarms, configuration integrity, or required clinical functionality, it should be:
- Removed from service.
- Labeled Out of Service.
- Sent for repair or bench evaluation as appropriate.
- Evaluated using approved Vyaire documentation and authorized IT/Clinical Engineering tools.
- Updated or configured only by qualified personnel using approved software and processes.
- Subjected to complete required post-update or post-repair functional, alarm, configuration, and ventilator-performance testing before clinical return.
If ventilation remains fully functional and only a non-safety-related integration function is affected, follow facility policy regarding restricted use and alternate documentation workflows. Knowing when the problem requires IT escalation rather than deeper ventilator troubleshooting is proper troubleshooting.
Clinical Use Tip
After restoring connectivity, verify the entire data path to the receiving system; a network-link indication on the ventilator alone does not prove successful clinical data transfer.
Work Order Documentation (CCR Method)
CCR = Complaint, Cause, Resolution
Complaint
What was reported by the clinical staff.
Example:
"Respiratory Therapy reported the bellavista 1000 was ventilating normally but patient data was no longer reaching the connected clinical system."
Cause
What was observed during troubleshooting.
Example:
"Clinical Engineering found the external network cable had a damaged connector and did not maintain a reliable link."
Resolution
What action was taken.
Example:
"Clinical Engineering replaced the cable with an approved known-good cable, verified network connectivity and end-to-end data transfer, confirmed normal ventilator operation, and returned the device to service."
Helpful Details to Include (If Known)
- Exact network, export, or update symptom
- Displayed communication message
- Last known successful connection or export
- Network cable and connector condition
- Port or link status
- Infrastructure port tested
- Authorized network configuration observed
- Receiving-system availability
- Export-media condition
- Software-update package or version involved
- End-to-end transfer result
- Final ventilator and communication status
Final Thought
Communication failures should be isolated systematically from the physical connection through the network and receiving system before blaming the ventilator. Protect clinical workflow, avoid unauthorized configuration or software changes, verify the entire path after correction, and escalate appropriately when the fault exceeds external troubleshooting.
That is successful troubleshooting.