On this page
Asset Type
Manufacturer
Model
What This Guide Helps With
Audible alarms, network communication, or case-data export fail because of settings, cabling, infrastructure, external devices, configuration, or service-level faults.
Step-by-Step Troubleshooting
1. Protect the Patient and Identify Which Function Failed
An alarm-speaker failure is a direct patient-safety concern. Do not use a machine clinically if required audible alarms cannot be verified.
For network or data-export problems, determine whether core anesthesia functions remain normal and whether clinical workflow can safely continue under facility policy.
Expected outcome: The complaint is separated into alarm, network, or data-export failure, and patient safety is protected.
2. Verify the Alarm Speaker Independently
Run the appropriate normal alarm or checkout test and confirm audible output from the machine.
Do not rely only on the absence of staff complaints.
Expected outcome: Required audible alarms are clearly produced. If the alarm speaker fails verification, remove the machine from service and escalate after basic external checks.
3. Check Alarm Settings and Audio Obstruction
Confirm alarm volume and related user-accessible settings have not been changed unexpectedly. Inspect the speaker opening for obvious obstruction or contamination.
Do not alter protected alarm configuration outside authorized procedures.
Expected outcome: Alarm settings are appropriate and the speaker path is unobstructed.
4. Inspect Network Cabling
For network complaints, inspect the Ethernet cable, connector, wall jack, patch connection, or approved wireless/network hardware applicable to the installed configuration.
Check for loose plugs, damaged latches, crushed cables, or disconnected infrastructure.
Expected outcome: Physical network connections are secure and undamaged. Correct an external connection issue and retest communication.
5. Compare With a Known-Good Network Connection
If facility policy allows, test the machine using a known-good approved network cable or known-good wall port serving equivalent equipment.
Do not change VLAN, IP, security, or enterprise network settings without authorization.
Expected outcome: If communication works on the known-good connection, the original cable, port, or infrastructure path is the likely cause.
6. Confirm Device Network Status
Review normal accessible network-status indications and record whether the machine appears connected, disconnected, or unable to reach the intended destination.
Do not make unsupported network configuration changes simply to establish connectivity.
Expected outcome: The failure is localized to the physical link, infrastructure, destination system, or machine communication function.
7. Verify the Receiving System
For exported case data, confirm the receiving server, documentation platform, integration system, or connected destination is available.
Check whether other comparable anesthesia machines are successfully transmitting.
Expected outcome: If multiple devices are affected, escalate to the appropriate IT or integration team rather than treating each Flow-e as defective.
8. Inspect Export Media or External Accessories
If case data is exported through approved removable media or another accessory, inspect the media or interface for compatibility, damage, connection problems, or write restrictions.
Use a known-good approved device or media when available.
Expected outcome: Data export succeeds using the supported pathway. If one external device is isolated as faulty, remove or replace it and verify again.
9. Perform End-to-End Verification
For alarm repairs, verify audible alarms through the applicable checkout. For network or export repairs, confirm data reaches the actual intended destination rather than merely showing a local connected status.
Expected outcome: Alarm output is audible and/or communication is verified end to end. Troubleshooting can stop when the affected function and full machine checkout are successful.
10. Escalate the Appropriate Failure Domain
If the alarm speaker fails despite correct settings and no obstruction, remove the machine from service for qualified repair.
If network or export failure persists after cables and local connections are ruled out, involve the appropriate IT, integration, or vendor support team while keeping Clinical Engineering responsible for confirming the device-side condition.
Expected outcome: The unresolved issue is escalated to the correct service domain without unnecessary internal disassembly or unauthorized configuration changes.
If the Problem Persists
Common external alarm-setting, speaker-obstruction, network-cabling, wall-port, destination-system, and export-accessory causes have been ruled out.
Remaining categories may include:
- Internal alarm-audio hardware.
- Internal communications hardware.
- Software or application problems.
- Device network configuration.
- Facility network or security infrastructure.
- Integration-engine or receiving-system problems.
- Service-level data-export configuration.
The Flow-e should be removed from service if required alarm functions cannot be verified. For communication-only problems, clinical disposition should follow facility risk and workflow requirements.
When device repair is required, the unit should be:
- Labeled Out of Service as appropriate.
- Sent for repair or bench evaluation.
- Evaluated using approved Getinge documentation and test equipment.
- Repaired or configured only by qualified personnel.
Do not make unauthorized enterprise network changes or protected device-configuration changes. Knowing whether the failure belongs to Clinical Engineering, IT, integration, or the vendor is part of proper troubleshooting.
Return to service after required alarm testing, communication verification when applicable, full checkout, and any required electrical-safety testing.
Clinical Use Tip
A network failure may affect documentation, but a failed audible alarm changes the immediate clinical safety status of the anesthesia machine.
Work Order Documentation (CCR Method)
CCR = Complaint, Cause, Resolution
Complaint
What was reported by the clinical staff.
Example:
"Anesthesia staff reported that a Flow-e was functioning clinically but would not export completed case data to the connected hospital system."
Cause
What was observed during troubleshooting.
Example:
"Clinical Engineering found the network cable at the anesthesia machine partially disconnected, resulting in loss of network communication."
Resolution
What action was taken.
Example:
"Reseated the network cable, verified the network connection and successful end-to-end case-data transmission, completed machine checkout, and returned the unit to service."
Helpful Details to Include (If Known)
- Alarm, network, or export function affected
- Alarm speaker test result
- Alarm-volume setting observed
- Network link status
- Cable and wall-port condition
- Known-good cable or port tested
- Whether other machines are affected
- Receiving system availability
- Export method tested
- End-to-end verification result
- Final device status
Final Thought
Separate alarm safety from communication workflow issues, check simple external connections and infrastructure before assuming a machine failure, verify the entire communication path, and document clearly when escalation crosses into IT, integration, or vendor support.
That is successful troubleshooting.