Siemens Healthineers Symbia Evo

Acquisition Workstation, DICOM, Archive, or RIS/PACS Communication Failure

On this page

Asset Type

Nuclear Medicine System

Manufacturer

Siemens Healthineers

Model

Symbia Evo

What This Guide Helps With

Troubleshooting Symbia Evo workstation, DICOM send, archive, RIS/PACS, worklist, or study transfer failures before repair escalation.

Step-by-Step Troubleshooting

Ensure Patient Safety First

Confirm the Symbia Evo is not actively acquiring a patient study before restarting workstations, disconnecting cables, or changing network connections.

If a study is in progress, coordinate with Nuclear Medicine staff before taking any action that could interrupt acquisition, reconstruction, or image transfer.

Expected outcome: Patient imaging and study data are protected before troubleshooting begins.

Confirm the Exact Communication Complaint

Ask the operator what failed and when it occurred.

Determine whether the issue involves:

Expected outcome: The issue is separated into workstation, network, DICOM destination, RIS, PACS, or archive workflow.

Check Whether Patient Images Are Safely Stored Locally

Confirm with the operator that the study is still available on the acquisition workstation or local system storage.

Do not delete, reprocess, or repeat studies until image status is verified.

Expected outcome: Existing patient data is protected before communication troubleshooting continues.

Check for Obvious Workstation Errors

Review the acquisition workstation screen for application errors, frozen software, warning messages, failed transfers, or pending jobs.

If the workstation application is responsive, note the exact error message before clearing or restarting anything.

Expected outcome: The failure message is captured for documentation and possible escalation.

Verify Network Cable and Physical Connection

Check that the Ethernet cable is securely connected at the acquisition workstation, network wall jack, switch port if visible, and any approved network interface point.

Look for damaged cables, loose connectors, or missing link lights.

Expected outcome: A loose or disconnected network path is corrected. If communication restores, confirm study transfer and stop.

Check Workstation Network Status

Confirm the workstation shows an active network connection.

Look for disconnected adapter status, disabled network connection, invalid IP address, or no network access.

Expected outcome: The workstation has a valid network connection before DICOM or RIS/PACS troubleshooting continues.

Confirm Whether Other Networked Devices Are Affected

Ask Nuclear Medicine or imaging staff whether other systems can send to PACS, receive worklist, or access the archive.

If multiple imaging systems are affected, involve IT, PACS, or network support before assuming a Symbia Evo fault.

Expected outcome: The issue is identified as either device-specific or part of a wider network/PACS outage.

Check DICOM Destination Selection

Verify the operator is sending to the correct destination, such as PACS, archive, processing workstation, or nuclear medicine review station.

Confirm that the failed study was not accidentally queued to the wrong destination.

Expected outcome: Incorrect destination selection is ruled out or corrected.

Review the Transfer Queue

Check whether studies are pending, failed, retrying, or blocked behind another failed transfer.

If the system allows safe resend or retry from the queue, retry only after confirming patient data is intact and the destination is correct.

Expected outcome: A stuck or failed transfer is identified and retried appropriately. If transfer succeeds, document and stop.

Confirm RIS Worklist Behavior

If the issue involves worklist, check whether the workstation can query RIS and whether scheduled patients appear correctly.

Confirm the date, modality, station name, location, or query filters are not limiting the displayed worklist.

Expected outcome: Worklist failure is separated from incorrect search filters or scheduling workflow.

Verify Date and Time

Check that the acquisition workstation date and time are correct.

Incorrect time settings can interfere with worklist queries, study matching, archive behavior, and troubleshooting logs.

Expected outcome: Time-related communication or matching problems are ruled out.

Check for Recent Changes

Ask whether there were recent changes to:

Expected outcome: The issue is linked to a recent system, network, or workflow change if applicable.

Test Basic Network Reachability if Available

If permitted by site policy and system access, use approved workstation tools to confirm whether the system can reach the DICOM destination, gateway, or server.

Do not make configuration changes without confirming the correct values with IT or PACS support.

Expected outcome: Network reachability is confirmed or the issue is escalated to IT/PACS with clear findings.

Check Archive or PACS System Status

Confirm whether the archive or PACS destination is online, accepting studies, and not in maintenance or downtime.

A receiving system problem can look like a nuclear medicine system failure.

Expected outcome: The receiving endpoint is verified before blaming the acquisition workstation.

Restart Only When Safe and Appropriate

If the acquisition workstation application is frozen or communication services appear unresponsive, coordinate with Nuclear Medicine staff before restarting the application or workstation.

Make sure no active acquisition, reconstruction, or transfer would be interrupted.

Expected outcome: A safe restart clears temporary software or communication lockups. If communication restores, confirm successful transfer and stop.

Verify Successful Study Transfer

After any corrective action, have staff confirm the study appears at the intended destination with correct patient demographics, image series, and accession information.

Expected outcome: The issue is resolved only after the receiving system confirms the study is present and usable.

If the Problem Persists

If power, workstation status, network connection, destination selection, transfer queue, worklist filters, and known IT/PACS issues have been ruled out, the problem may involve internal workstation software, DICOM configuration, network interface hardware, database services, or Siemens application-level communication.

The Symbia Evo should be removed from clinical use if studies cannot be safely acquired, stored, transferred, or matched to patient orders.

The device should be:

Knowing when to stop is proper troubleshooting. Do not perform unsupported DICOM configuration changes, software repairs, or database-level actions without the proper service access and authorization.

Clinical Use Tip

Do not troubleshoot communication failures during an active patient acquisition unless the system is already stopped or the clinical team has confirmed it is safe. Protect the acquired study first, then troubleshoot transfer, archive, or worklist issues.

Work Order Documentation (CCR Method)

CCR = Complaint, Cause, Resolution

Complaint

What was reported by the clinical staff.

Example:
"Nuclear Medicine reported that Symbia Evo studies were not transferring from the acquisition workstation to PACS after completion."

Cause

What was observed during troubleshooting.

Example:
"Found studies held in the transfer queue after confirming the workstation network cable and DICOM destination were correct; PACS connectivity was restored after safe workstation application restart."

Resolution

What action was taken.

Example:
"Restarted the acquisition workstation application with Nuclear Medicine approval, resent the queued study, confirmed image arrival in PACS, and returned the system to service."

Helpful Details to Include (If Known)

Final Thought

Symbia Evo communication troubleshooting should protect patient data first, then move logically through workstation status, physical network checks, DICOM destination selection, queue status, and RIS/PACS availability. Escalation is appropriate when external causes have been ruled out or when patient study integrity could be affected. Clear CCR documentation helps show what failed, what was checked, and how the final clinical status was confirmed.

That is successful troubleshooting.

Related Guides

Was this guide helpful?

Don't see a guide you need?

Suggest a Guide