On this page
Asset Type
Manufacturer
Model
What This Guide Helps With
Addresses failures in sending images or studies to PACS due to network issues, DICOM configuration errors, or system communication faults before assuming hardware failure.
Step-by-Step Troubleshooting
Ensure Patient Safety
Confirm no patient is dependent on immediate image transfer. Perform troubleshooting on completed studies or with a test patient to prevent disruption.
Check Network Connectivity
- Verify Ethernet/Wi-Fi connections are secure and the system has network access.
- Ping the PACS server from the system if possible.
- Expected Outcome: Network responds; no packet loss.
- Why: DICOM export requires reliable network communication.
Verify PACS/DICOM Settings
- Confirm correct AE Title, IP address, port, and DICOM node configuration in the system.
- Check that the PACS server is set to accept connections from this device.
- Expected Outcome: Settings match PACS server.
- Why: Incorrect configuration prevents study transfer.
Test with Another Study or Modality
- Export a small test study or image set.
- Expected Outcome: Test study successfully exports.
- Why: Confirms whether the issue is study-specific or system-wide.
Check for Software or Export Queues
- Look for any stuck DICOM queues or software alerts on the LOGIQ system.
- Restart the DICOM service or system if allowed.
- Expected Outcome: Queue clears, export resumes.
- Why: Stalled queues or software errors often block new exports.
Review Storage Media and Permissions
- Ensure the system has access to local storage if the PACS workflow uses intermediate caching.
- Confirm sufficient disk space and proper folder permissions.
- Expected Outcome: No storage errors reported.
- Why: Insufficient storage or permission errors can block DICOM export.
Check Firewall or Security Restrictions
- Confirm that firewalls, antivirus, or network policies are not blocking DICOM ports (usually TCP 104 or configured port).
- Expected Outcome: DICOM port allowed; connection established.
- Why: Network security measures may silently block DICOM transfer.
If the Problem Persists
If all external causes—network, configuration, queues, and storage—have been ruled out, the issue is likely internal software or DICOM stack corruption.
- Remove the system from PACS workflow.
- Label as Out of Service for DICOM export.
- Escalate to GE service or in-house repair bench for software evaluation.
Clinical Use Tip
Always move the patient or study to another functioning system before attempting extended troubleshooting.
Do not interrupt imaging on active patients for network troubleshooting.
Work Order Documentation (CCR Method)
CCR = Complaint, Cause, Resolution
Complaint
What was reported by the clinical staff.
Example:
"Unable to send completed studies to PACS; export fails with network error."
Cause
What was observed during troubleshooting.
Example:
"Network and DICOM configuration verified; export queue cleared, but failures persist."
Resolution
What action was taken.
Example:
"System removed from PACS workflow and labeled Out of Service; sent for service evaluation."
Helpful Details to Include (If Known)
- Network connectivity check results
- DICOM AE Titles and IP addresses
- Export queue status
- Software version and recent updates
- Any error codes or messages
Final Thought
DICOM export issues often stem from external factors like network settings or misconfigured nodes. Following a structured, logic-based troubleshooting path ensures patient safety, avoids unnecessary internal repair, and provides clear documentation for service escalation.
That is successful troubleshooting.