On this page
Asset Type
Manufacturer
Model
What This Guide Helps With
Addresses unavailable logs, trends, or serial data caused by connection, media, port, configuration, workstation, communication, or service-access problems.
Step-by-Step Troubleshooting
1. Preserve Patient Safety and Ventilation
A data-export problem alone should not interrupt needed ventilation. Do not disconnect required patient circuits or compromise therapy simply to troubleshoot a communications or export feature.
If the export problem is associated with freezing, rebooting, alarm loss, or other unreliable ventilator behavior, move the patient to another verified ventilator before continuing.
Expected outcome: Patient ventilation remains uninterrupted and any unreliable ventilator is removed from active use before troubleshooting.
2. Confirm Which Data Function Is Unavailable
Determine whether the complaint involves the event log, trend review, serial output, external data capture, or more than one function.
Record whether the data can still be viewed locally and whether the problem is specifically with exporting or transmitting it.
Expected outcome: The affected function is clearly identified. If the data is available and exports normally during retest, document the result and complete verification.
3. Confirm the Requested Data Exists
Verify through normal accessible controls that the ventilator contains the expected trend, event, or historical information.
Do not assume an export failure when the requested information was never recorded or has already rolled out of available history.
Expected outcome: The desired information is present locally and should be available for the intended export or communication process.
4. Inspect External Cables and Connectors
Inspect the applicable serial or communication cable for damage, bent contacts, loose connectors, strain, contamination, or an incorrect cable type.
Reseat both ends of the connection.
Expected outcome: The cable is intact and securely connected. If reseating restores communication, perform a repeat export to verify the correction.
5. Substitute a Known-Good Cable or Receiving Device
When practical, test with a known-good compatible communication cable.
If possible, use a known-good approved receiving computer, terminal, interface, or data-capture device to distinguish a ventilator problem from an external system problem.
Expected outcome: Successful operation with the known-good external component identifies the original cable or receiving system as the likely cause. Troubleshooting can stop after repeat verification.
6. Verify the Correct Port Is Being Used
Confirm that the connection is made to the intended external communications port and that the connector is fully seated.
Do not connect equipment to undocumented ports or service connectors simply because the plug fits.
Expected outcome: The approved communications port is being used correctly. If the wrong port was selected, reconnect appropriately and repeat the test.
7. Verify External Communication Settings
Check the approved communication settings on the receiving system against the documented configuration required for the VELA installation.
Do not guess at serial parameters, change undocumented ventilator settings, or modify restricted service configuration without authorized information.
Expected outcome: The receiving device and ventilator are configured compatibly according to known documentation. If a verified external configuration mismatch is corrected and export resumes, proceed to final verification.
8. Check the Receiving Workstation or Interface
Confirm the receiving computer or interface is powered, responsive, connected, and using the intended application or data-capture process.
Look for disabled ports, incorrect port selection, software lockup, or another obvious workstation-side problem.
Restarting or reconfiguring external systems should follow facility IT and application support procedures.
Expected outcome: The receiving system is operational and ready to accept data. If correcting the workstation restores export, document that the ventilator itself was functioning normally.
9. Determine Whether the Failure Is Isolated or System-Wide
If multiple VELA ventilators use the same receiving system, compare another known-good unit when operationally appropriate.
A failure affecting several ventilators connected to the same workstation or infrastructure points toward the external system rather than simultaneous ventilator failure.
Expected outcome: The problem is isolated to either the individual ventilator or the shared receiving environment.
10. Perform a Controlled Data-Transfer Test
Using approved accessories and a known-good receiving system, attempt a controlled export or serial communication test.
Confirm that expected data is received completely and without repeated disconnects or corrupted output.
Expected outcome: Event, trend, or serial data transfers successfully and repeatably. If successful, troubleshooting can stop after documenting the tested path.
11. Escalate Persistent Ventilator-Side Communication Failure
If known-good cables and receiving systems have been tested, configuration is verified, and the failure remains isolated to the ventilator, stop external troubleshooting.
Do not open the ventilator to probe internal communication boards, connectors, storage devices, or control circuitry without approved service procedures.
Expected outcome: The ventilator is removed from service if the required communication function is necessary for clinical workflow, compliance, or integration, and it is routed for qualified evaluation.
If the Problem Persists
Common external cable, receiving-system, connection, and configuration causes have been ruled out. Remaining causes may involve the ventilator's communication interface, internal storage or logging function, software configuration, control electronics, or another service-level issue.
The ventilator should be:
- Removed from service when the unavailable function is required for safe clinical operation or required workflow.
- Labeled Out of Service when removal is indicated.
- Sent for repair or bench evaluation.
- Evaluated using appropriate manufacturer documentation and approved test equipment.
- Repaired or configured only by qualified personnel.
After service, verify the complete communication path, data availability, export function, and normal ventilator operation before return to service. Knowing when to stop external troubleshooting is proper troubleshooting.
Clinical Use Tip
When serial data feeds a clinical information system, verify the complete path to the receiving system rather than assuming a successful physical connection means data is being recorded.
Work Order Documentation (CCR Method)
CCR = Complaint, Cause, Resolution
Complaint
What was reported by the clinical staff.
Example:
"Respiratory Therapy reported that event and trend information could be viewed on the Vyaire VELA but could not be transferred to the connected data-capture workstation."
Cause
What was observed during troubleshooting.
Example:
"Clinical Engineering found the external serial communication cable had an intermittent connection at the workstation end."
Resolution
What action was taken.
Example:
"The defective cable was replaced with a known-good compatible cable, repeated data transfers completed successfully, and normal ventilator operation was verified."
Helpful Details to Include (If Known)
- Exact data function affected.
- Whether the information was visible locally.
- Port used.
- Cable condition.
- Known-good cable test result.
- Receiving workstation or interface tested.
- Communication settings observed.
- Whether another VELA communicated successfully.
- Whether the problem affected one device or multiple devices.
- Result of the final data-transfer test.
- Final ventilator status.
Final Thought
Data-export failures should be isolated across the entire communication path before the ventilator is blamed. Protect ventilation, verify the data exists, test connections and receiving equipment first, escalate isolated ventilator failures appropriately, and document both the cause and the final transfer verification.
That is successful troubleshooting.