On this page
Asset Type
Manufacturer
Model
What This Guide Helps With
Troubleshooting PET/CT study transfer, DICOM send, archive, RIS/PACS, or network communication failures using external checks first.
Step-by-Step Troubleshooting
Ensure Patient Safety First
Confirm the patient exam is complete or that the patient has been safely moved away from the scanner before troubleshooting.
Do not interrupt an active acquisition, reconstruction, or image review workflow unless clinical staff confirm it is safe.
Expected outcome: Patient care is not delayed or interrupted by network troubleshooting.
Confirm the Exact Transfer Problem
Ask technologists what failed and when it failed.
Identify whether the issue involves:
- PET study not sending
- CT study not sending
- Fused PET/CT images not transferring
- DICOM send failure
- Archive failure
- RIS worklist issue
- PACS destination unavailable
- Study stuck in queue
- Study sent but not visible in PACS
Expected outcome: The failure is clearly separated between acquisition, reconstruction, DICOM routing, RIS, PACS, or archive workflow.
Verify the Study Is Complete and Ready to Send
Confirm the PET, CT, and fused image series are fully reconstructed and available at the workstation.
A study may fail to transfer if reconstruction is incomplete, the study is still open, or the final series has not been generated.
Expected outcome: The correct image series are present and ready for DICOM transfer.
If the study completes reconstruction and sends successfully, stop troubleshooting.
Check for Local System Messages
Review the acquisition workstation, syngo workstation, or transfer queue for DICOM, network, archive, or database messages.
Look for messages such as destination unavailable, association failed, storage commit failed, connection timeout, unknown host, or queue stopped.
Expected outcome: The displayed message helps narrow the issue before changing anything.
Confirm Whether the Problem Affects One Study or All Studies
Check whether only one patient study failed or whether multiple studies are failing.
If only one study is affected, suspect study-specific data, incomplete reconstruction, demographic mismatch, or routing selection.
If all studies are affected, suspect network, destination, AE title, IP address, port, PACS availability, or system communication issue.
Expected outcome: The scope of the issue is defined.
Check the DICOM Transfer Queue
Open the send/archive queue and confirm whether studies are pending, failed, paused, or actively retrying.
Restarting a failed send from the queue may be appropriate if the system allows it and the destination is available.
Expected outcome: The queue status confirms whether the system is attempting transfer.
If restarting the send resolves the issue and the study appears in PACS, stop troubleshooting.
Verify the Correct Destination Was Selected
Confirm the technologist selected the correct DICOM destination, PACS archive, or configured send target.
PET/CT systems may have multiple destinations, such as PACS, oncology workstation, radiation therapy planning system, nuclear medicine archive, or test destinations.
Expected outcome: The study is being sent to the intended clinical destination.
Confirm RIS/Worklist Information
If the issue involves worklist, accession number, or study matching, confirm that the patient demographics and accession number match the order in RIS.
Check for duplicate patients, wrong accession number, missing order, canceled order, or manually entered demographics.
Expected outcome: RIS and image study information match closely enough for PACS reconciliation.
If demographic correction by authorized staff resolves the transfer issue, stop troubleshooting.
Check Basic Network Connectivity
Confirm the workstation or system network cable is connected, seated firmly, and undamaged.
Check the wall data jack, patch cable, and any visible network switch connection if accessible.
Expected outcome: No obvious disconnected or damaged network path is found.
Look for Network Link Indicators
Check for active link lights at the workstation network port, wall-connected equipment, or nearby accessible switch port if allowed by site policy.
No link light may indicate a disconnected cable, bad patch cable, inactive port, or network infrastructure issue.
Expected outcome: Network link appears active.
Confirm Other Network Functions
Ask staff whether other network-dependent functions are working, such as RIS worklist, prior study access, PACS query/retrieve, remote archive, or modality performed procedure step.
Expected outcome: The issue is narrowed to one destination or a broader network failure.
Check Whether Other Modalities Are Affected
Contact imaging staff, PACS support, or IT to determine whether CT, MRI, nuclear medicine, or other modalities are also having send failures.
If multiple modalities are affected, the issue is more likely PACS, network, archive, or interface-related rather than isolated to the Biograph Horizon.
Expected outcome: Sitewide versus device-specific impact is determined.
Confirm PACS or Archive Availability
Ask PACS or imaging IT support whether the destination server is online and accepting DICOM connections.
A PET/CT scanner may appear faulty when the receiving archive, DICOM listener, storage server, or interface engine is down.
Expected outcome: The receiving system is confirmed available or identified as the cause.
Verify No Recent Network or PACS Changes Occurred
Ask whether there were recent changes to:
- PACS server
- IP address
- AE title
- DICOM port
- Firewall rules
- VLAN or network switch
- Archive routing rules
- RIS interface
- Modality replacement or software update
Expected outcome: Recent changes are identified before assuming equipment failure.
Do Not Randomly Change DICOM Settings
Do not change AE titles, IP addresses, ports, hostnames, or routing rules unless directed by Siemens service, PACS administration, or site imaging IT.
Incorrect DICOM changes can break study routing, create duplicate destinations, or prevent proper archive reconciliation.
Expected outcome: Configuration integrity is protected.
Attempt a Controlled Test Send
If allowed by site policy, send a known completed test or non-patient study to the intended destination.
Coordinate with PACS support so they can confirm whether the DICOM association, image receipt, and archive commit occur.
Expected outcome: The team confirms whether data leaves the Biograph Horizon and reaches PACS.
Check for Local Storage or Database Warnings
Review whether the workstation reports low disk space, database issues, or archive queue overload.
A full local disk or database issue can prevent studies from exporting properly even when the network is functional.
Expected outcome: Local storage or database-related causes are identified.
Restart Only When Safe and Approved
If the system is not in clinical use and site policy allows, perform an orderly restart of the affected workstation or application.
Do not power-cycle scanner components during active patient care, active reconstruction, or while a study is mid-transfer unless directed by service.
Expected outcome: Temporary software or queue communication issues may clear.
If transfer resumes and studies appear in PACS, document the result and stop troubleshooting.
Escalate With Specific Information
If the issue remains unresolved, escalate to the appropriate support group with the exact symptom, queue message, affected studies, destination, time of failure, and whether other modalities are affected.
Expected outcome: Siemens service, PACS, or imaging IT receives useful information instead of a vague “not sending” report.
If the Problem Persists
If the Biograph Horizon still cannot send, archive, query RIS, or transfer studies after external checks, common user-accessible causes have been ruled out.
The issue may involve internal workstation software, DICOM configuration, database services, network interface hardware, PACS listener configuration, RIS interface failure, or archive-side communication.
The device should be:
- Removed from clinical use if study transfer failure affects patient care or prevents required image availability
- Labeled Out of Service if the system cannot safely support the clinical workflow
- Escalated to Siemens service, PACS support, imaging IT, or bench/service evaluation as appropriate
Knowing when to stop is proper troubleshooting. Do not perform unsupported configuration changes or internal repair attempts on the PET/CT system.
Clinical Use Tip
Do not troubleshoot DICOM or archive failures while a patient is actively being scanned unless the clinical team confirms it is safe. Complete or pause patient care appropriately first, then troubleshoot the transfer issue. If images are needed urgently for care decisions, clinical staff should use the approved downtime or alternate image access process.
Work Order Documentation (CCR Method)
CCR = Complaint, Cause, Resolution
Complaint
What was reported by the clinical staff.
Example:
"Technologist reported that Biograph Horizon PET/CT studies were failing DICOM send to PACS after reconstruction."
Cause
What was observed during troubleshooting.
Example:
"Verified PET and CT series were complete, network cable was connected, but transfer queue showed repeated destination timeout to the PACS archive."
Resolution
What action was taken.
Example:
"Confirmed issue with PACS support, left completed studies queued for retry, escalated to imaging IT/Siemens, and kept system available only per clinical leadership approval."
Helpful Details to Include (If Known)
- Whether PET, CT, fused, or all series failed to send
- Exact DICOM error or queue message
- Whether RIS worklist was available
- Whether PACS query/retrieve worked
- Whether other modalities were affected
- Destination name selected
- Time and date of failed transfer
- Accession number or study identifier per site policy
- Network cable and link light status
- Whether a test send was attempted
- Whether restart was performed
- Final device status
Final Thought
PET/CT transfer problems should be handled logically: protect the patient first, confirm the study and destination, check the visible network path, and involve PACS or IT before assuming scanner failure. Good documentation helps separate device issues from archive, RIS, and network problems.
That is successful troubleshooting.