On this page
Asset Type
Manufacturer
Model
What This Guide Helps With
Troubleshooting Cios Alpha DICOM or PACS export failures caused by network, destination, patient data, or configuration issues.
Step-by-Step Troubleshooting
1. Ensure Patient Safety First
Before troubleshooting, confirm the C-arm is not actively needed for a procedure.
Action:
- Do not troubleshoot DICOM export during an active case unless clinical staff confirms it is safe.
- Confirm images needed for patient care are still visible locally on the Cios Alpha.
- If imaging is urgently needed, allow the clinical team to continue using the system locally while export troubleshooting waits.
- Do not delete studies, exams, or patient data during troubleshooting.
Expected outcome: Patient care continues safely, and stored images are protected.
Why it matters: A DICOM/PACS export issue is usually a connectivity or workflow issue, but accidental deletion or interruption during a case can create a patient care risk.
2. Verify the Reported Export Failure
Confirm exactly what is failing.
Action:
- Ask whether the issue affects one study, one patient, one destination, or all exports.
- Check whether the export fails immediately, stays queued, times out, or reports a specific DICOM/network error.
- Confirm whether images are stored locally on the C-arm.
- Try exporting a non-critical test or completed study if permitted by site policy.
Expected outcome: You identify whether this is a single-study issue, destination issue, or system-wide export problem.
If export works for other studies or destinations, stop broad troubleshooting and focus on the affected study, patient data, or destination.
3. Confirm the C-Arm Is Connected to the Network
Check the simplest external network causes first.
Action:
- Verify the network cable is connected securely to the Cios Alpha or docking/network connection point.
- Confirm the cable is connected to the correct wall jack or network switch port.
- Look for link/activity lights at the network jack, switch, or adapter if visible.
- If the system uses a docking station, cart interface, or hospital network drop, reseat the connection.
Expected outcome: The C-arm has a valid physical network connection.
If a loose or disconnected cable is found, reconnect it and retry export. If the export succeeds, document the cable/network connection issue and stop.
4. Test With a Known-Good Network Drop or Cable
Rule out a bad cable, jack, or local network path.
Action:
- Swap the Ethernet cable with a known-good cable if available.
- Move to a known-working network jack approved for imaging/PACS traffic if practical.
- Avoid using random public or non-clinical network ports unless IT confirms they are configured correctly.
- Confirm whether other imaging devices on the same network area are exporting normally.
Expected outcome: The export either works on a known-good connection or continues to fail.
If the export works after changing the cable or network drop, the original cable, jack, or network path is the likely cause. Stop and document the finding.
5. Check for Local Network Address Problems
Confirm the system appears to have normal network connectivity.
Action:
- Review the C-arm network status/settings if accessible under normal user or service-permitted menus.
- Look for missing IP address, incorrect subnet, gateway issue, or disconnected network status.
- Confirm whether the device is configured for DHCP or static IP according to site standards.
- Compare the displayed network information to the hospital’s expected configuration, if available.
Expected outcome: The C-arm has a valid network identity for the imaging network.
If the IP address is missing, incorrect, duplicated, or outside the expected range, escalate to IT/PACS support or approved service support before changing network configuration.
6. Confirm the Correct DICOM/PACS Destination Is Selected
A wrong destination can look like a device failure.
Action:
- Verify the selected export destination is the correct PACS, archive, workstation, or DICOM node.
- Confirm the destination name matches the site workflow.
- If multiple destinations exist, try a known-good destination if permitted.
- Ask staff whether a recent PACS, network, or destination change occurred.
Expected outcome: The system is attempting export to the correct destination.
If another DICOM destination works, the issue is likely destination-specific rather than a total C-arm failure.
7. Verify Patient and Study Information
Incorrect or incomplete patient/study data can interfere with DICOM workflow.
Action:
- Confirm the patient name, patient ID/MRN, accession number, study date, and modality information are entered correctly.
- Check for unusual characters, missing required fields, duplicate patient entries, or mismatched accession numbers.
- Confirm whether the study was created through the expected worklist process or manually entered.
- If the problem is limited to one patient or exam, compare it with a study that exported successfully.
Expected outcome: Required DICOM fields are complete and reasonable.
If correcting patient/study information allows export, document the data issue and stop.
8. Check Modality Worklist or Order Association
If the site uses modality worklist, export may depend on proper order selection.
Action:
- Confirm the exam was selected from the correct worklist entry when applicable.
- Verify the accession number and patient identifiers match the order in the hospital system.
- Ask clinical staff whether the case was performed under an emergency/manual entry workflow.
- If the worklist is not loading or patient data does not match, involve PACS/RIS/IT support.
Expected outcome: The exported study is properly associated with the correct order.
If the study exports after proper order association, the issue was likely workflow or demographic mismatch.
9. Review the Export Queue
Check whether studies are stuck, pending, failed, or repeatedly retrying.
Action:
- Open the export, send, archive, or network queue if available.
- Look for failed studies, repeated retries, or a backlog of unsent exams.
- Confirm whether all studies are stuck or only one study is failing.
- Do not clear, delete, or purge queued studies unless approved by clinical leadership and site policy.
Expected outcome: You determine whether the problem is a queue backlog, a single failed study, or total DICOM communication failure.
If one study is blocking the queue, escalate to PACS/IT or vendor support before deleting or altering data.
10. Confirm PACS or DICOM Destination Availability
The C-arm may be functioning normally while the receiving system is unavailable.
Action:
- Ask PACS/IT whether the destination is online and accepting DICOM studies.
- Confirm whether other modalities are sending successfully to the same destination.
- Verify whether there was recent PACS maintenance, network maintenance, firewall change, or server migration.
- Check whether the destination AE Title, IP address, and port may have changed.
Expected outcome: The receiving PACS/DICOM node is confirmed available.
If other devices also cannot export, the issue is likely PACS, network, or destination-side rather than the Cios Alpha.
11. Check for Recent Configuration Changes
Determine whether the issue started after a change.
Action:
- Ask staff when export last worked.
- Check whether the C-arm was moved to a different room, network jack, or OR.
- Ask whether the hospital changed PACS, VLANs, firewall rules, IP ranges, AE Titles, or ports.
- Review recent service activity, software updates, or network configuration changes.
Expected outcome: You identify whether the failure began after a known environmental or configuration change.
If the issue began after a network or PACS change, coordinate with IT/PACS and vendor support as needed.
12. Power Cycle Only When Safe
A restart may clear a temporary software or communication hang, but it should not interrupt care.
Action:
- Confirm the C-arm is not being used for an active procedure.
- Verify images are stored locally before restarting.
- Perform a normal shutdown and restart according to site procedure.
- After restart, confirm the system boots normally and retry export.
Expected outcome: Temporary software or network session issues may clear.
If export succeeds after restart, monitor for recurrence and document the restart as the corrective action.
13. Escalate for DICOM Configuration or Internal Fault Evaluation
Do not guess or make unauthorized DICOM configuration changes.
Action:
- Escalate to PACS/IT if network reachability, AE Title, IP address, port, firewall, worklist, or destination availability is suspected.
- Escalate to Siemens service or approved imaging service support if the C-arm appears to have a software, storage, DICOM service, or internal communication issue.
- Preserve failed export details, error messages, timestamps, patient/study identifiers, and destination name for support.
Expected outcome: The correct support team receives enough information to isolate the failure.
If the Problem Persists
If the Cios Alpha still cannot export after checking network connection, cable, network drop, destination selection, patient data, worklist association, export queue, and PACS availability, the issue is likely configuration-related, software-related, network-side, or internal to the system.
The device should be:
- Removed from clinical use if images cannot be reliably stored, retrieved, or exported according to site workflow.
- Labeled Out of Service if the failure affects clinical availability or required image transfer.
- Sent for repair, imaging service evaluation, or PACS/IT escalation as appropriate.
Knowing when to stop is proper troubleshooting. DICOM and PACS problems often involve both the medical device and hospital network environment, so escalation should include accurate details rather than unnecessary internal disassembly.
Clinical Use Tip
Do not troubleshoot export workflow during an active procedure unless the clinical team confirms it is safe. If imaging is needed, allow the case to continue locally and resolve the PACS export issue after patient care is protected. Do not troubleshoot on an active patient when therapy or imaging continuity is at risk; move patient care to a backup device or workflow first.
Work Order Documentation (CCR Method)
CCR = Complaint, Cause, Resolution
Complaint
What was reported by the clinical staff.
Example:
"Clinical staff reported that the Siemens Healthineers Cios Alpha C-arm would not export images to PACS after a completed case."
Cause
What was observed during troubleshooting.
Example:
"Troubleshooting found the C-arm connected to a network wall jack that was not configured for the imaging/PACS network."
Resolution
What action was taken.
Example:
"Reconnected the C-arm to an approved imaging network port, verified local image storage, successfully exported a test study to PACS, and returned the unit to service."
Helpful Details to Include (If Known)
- Whether the issue affected one study or all studies
- Exact DICOM/export error message
- Date and time of failed export
- PACS destination selected
- Patient/study/accession issue noted, if applicable
- Accessories swapped, including Ethernet cable, docking connection, or network adapter
- Power behavior before and after restart
- Environmental factors, including room, network jack, OR, or recent relocation
- Network cable condition
- Network jack or room location used
- Whether link lights were present
- Whether other modalities could export
- Whether the worklist was functioning
- Whether a restart was performed
- Final export status
- Whether PACS/IT or Siemens service was contacted
- Final device status
Final Thought
DICOM/PACS export failures should be approached logically. Confirm patient safety first, then verify local image availability, network connection, destination selection, patient demographics, worklist association, and PACS availability. Avoid unnecessary internal repair assumptions until external network and workflow causes are ruled out. Clear CCR documentation helps Clinical Engineering, PACS, IT, and vendor support resolve the issue faster.
That is successful troubleshooting.