On this page
Asset Type
Manufacturer
Model
What This Guide Helps With
Addresses missing cycle transfers, export failures, or tracking-interface communication problems caused by cables, network access, destination availability, time, or configuration.
Step-by-Step Troubleshooting
1. Protect Traceability and Clinical Workflow
Use the facility’s approved downtime documentation process when electronic records are not reaching the required tracking system. Do not process endoscopes under incomplete or incorrect identifiers.
Confirm that completed cycle data remains available locally before restarting or making changes.
Expected outcome: Endoscope traceability is preserved while the communication path is evaluated.
2. Confirm the Exact Communication Failure
Determine whether the issue affects:
- All cycle records or selected records
- One chamber or both
- Network transmission
- USB or removable-media export
- Instrument tracking
- Patient or endoscope data import
- Printer output only
- A single destination or all destinations
Record the exact message, time of occurrence, and last known successful transfer.
Expected outcome: The affected portion of the communication workflow is clearly identified.
3. Verify Local Cycle Record Creation
Check that the AER generated and stored the complete cycle record. Confirm the cycle status, identifiers, date, and time.
If the record is absent locally, do not treat the issue as only a network problem.
Expected outcome: The source record is present and accurate, allowing the failure to be isolated downstream.
4. Inspect External Network Connections
Inspect the Ethernet cable, wall jack, patch connection, or approved network adapter. Look for:
- Loose connectors
- Broken locking tabs
- Damaged cable
- Pinched routing
- Connection to the wrong jack
- Missing link indicators where provided
- Recent equipment movement
Reseat accessible connections and test with a known-good approved cable when available.
Expected outcome: The physical network connection is secure. If the known-good cable restores transfer, troubleshooting can stop after verification.
5. Check the Network Outlet or Local Infrastructure
Confirm whether another approved device can communicate from the same network outlet, or whether the AER communicates when connected to a known-good authorized port.
Coordinate with Information Services before moving the AER to a different network segment.
Expected outcome: The wall port and local network path are confirmed operational or an infrastructure fault is identified.
6. Check Destination-System Availability
Determine whether the instrument-tracking server, data repository, interface engine, or receiving application is online. Ask Information Services or the application owner whether other devices are failing to transmit.
Avoid repeated retransmission if duplicate records could be created.
Expected outcome: The receiving system is available and accepting records, or a broader server/interface outage is confirmed.
7. Verify Date and Time
Check the AER’s displayed date and time against the facility standard. Significant mismatch can interfere with record matching, certificates, or interface processing.
Correct date and time only through authorized settings and facility procedures.
Expected outcome: The AER date and time are accurate and consistent with the receiving system.
8. Verify Authorized Communication Settings
Review visible, approved settings such as selected destination, export mode, network status, or interface enablement. Compare with a working unit or documented configuration.
Do not change IP addressing, security settings, certificates, ports, or protected interface parameters without coordination and authorization.
Expected outcome: The AER is configured to send data to the intended destination.
9. Test a Controlled Record Transfer
Use an approved stored record or verification cycle to test the complete path. Confirm the record reaches the correct destination with accurate cycle, operator, endoscope, and time information.
Check for queued records and manage duplicates according to policy.
Expected outcome: The record transfers correctly and appears at the receiving system. The issue is resolved, and troubleshooting can stop.
10. Stop and Escalate When Communication Remains Unreliable
If local records, cables, wall ports, time, destination availability, and visible settings are acceptable but communication still fails, escalate jointly to qualified service personnel and Information Services.
Do not modify protected network configuration or install unapproved software.
Expected outcome: The AER is either removed from service or operated only under an approved documented downtime process.
If the Problem Persists
Common physical connection, local-record, network-port, destination, and basic configuration causes have been ruled out. The remaining problem may involve interface software, authentication, certificates, server configuration, database mapping, network security, internal communication hardware, or application-level routing.
The AER should be:
- Removed from service when required by traceability policy
- Labeled Out of Service
- Sent for repair or qualified technical evaluation
- Evaluated using appropriate manufacturer documentation and approved test equipment
- Repaired or configured only by qualified personnel working with Information Services
Return to service requires successful end-to-end transfer, accurate data mapping, duplicate-record review, and confirmation at the receiving system. Knowing when to stop external troubleshooting is proper troubleshooting.
Clinical Use Tip
Verify the complete path from AER cycle completion to the final tracking-system record, not merely the network link indicator.
Work Order Documentation (CCR Method)
CCR = Complaint, Cause, Resolution
Complaint
What was reported by the clinical staff.
Example:
"Sterile Processing reported that Advantage Plus cycle records were stored locally but were not appearing in the instrument-tracking system."
Cause
What was observed during troubleshooting.
Example:
"Clinical Engineering found the Ethernet cable disconnected from the wall jack after the AER had been moved for floor cleaning."
Resolution
What action was taken.
Example:
"The cable was reconnected and secured, network status returned, and a verification-cycle record was confirmed at the tracking-system workstation."
Helpful Details to Include (If Known)
- Exact communication message
- Last successful transfer
- Local record availability
- Cable and wall-port condition
- Link indicators
- Known-good cable or port result
- Destination-system status
- Date and time accuracy
- Records queued
- Receiving-system confirmation
- Final device status
Final Thought
Protect traceability, verify the local record and physical network path before assuming an internal fault, test the complete interface end to end, escalate across Clinical Engineering and Information Services, and document every confirmed result.
That is successful troubleshooting.