Siemens Healthineers Ysio Max

DICOM Send, Modality Worklist, or Network Communication Failure

On this page

Asset Type

Radiographic System

Manufacturer

Siemens Healthineers

Model

Ysio Max

What This Guide Helps With

Troubleshooting Ysio Max DICOM send failures, missing Modality Worklist exams, or network communication issues before escalating for repair.

Step-by-Step Troubleshooting

Ensure Patient Safety First

Do not troubleshoot network or image transfer problems while delaying urgent patient care.

Action:

Expected outcome: Patient care continues while the communication issue is isolated.

Why it matters: A DICOM or worklist issue is usually not an exposure safety issue, but it can delay care, prevent image availability, or create documentation risk.

If this resolves the clinical workflow concern, document the downtime process and continue troubleshooting when safe.

Verify the Reported Communication Problem

Confirm exactly what part of the workflow is failing.

Action:

Expected outcome: The failure is narrowed to sending, receiving worklist data, network access, or destination availability.

Why it matters: A worklist failure, PACS send failure, and total network loss are different problems even though staff may report them all as “network down.”

Check for Hospital-Wide PACS, RIS, or Network Issues

Before assuming the Ysio Max is defective, determine whether other systems are affected.

Action:

Expected outcome: You determine whether the problem is isolated to the Ysio Max or part of a larger network/PACS/RIS issue.

If multiple systems are affected, stop device-level troubleshooting and document that the issue appears external to the Ysio Max.

Confirm the System Is Fully Powered and Logged In

Verify that the acquisition workstation and imaging system are in a normal ready state.

Action:

Expected outcome: The system is operational and not blocked by a login, software state, or obvious workstation error.

Why it matters: DICOM and worklist communication can fail if the workstation is not fully initialized, the imaging application is not running correctly, or system time is incorrect.

Check the Physical Network Connection

Inspect the external network connection before changing settings.

Action:

Expected outcome: The system has a secure physical network connection.

If the cable was loose or disconnected, reconnect it, allow the system to re-establish communication, then retry the worklist query or DICOM send.

If this resolves the issue, stop and document the correction.

Confirm the Correct Network Port or Wall Jack Is Being Used

Make sure the system is not connected to an inactive or wrong network drop.

Action:

Expected outcome: The Ysio Max is connected to an active network drop assigned for imaging equipment.

Why it matters: Radiographic systems often require specific network routing, firewall rules, VLAN access, or static addressing. A normal-looking network jack may not be configured for DICOM traffic.

Review the DICOM Send Queue

Check whether images are failing, pending, or waiting to send.

Action:

Expected outcome: You identify whether the system is creating images but failing during transmission.

If a retry succeeds, monitor the queue until it clears, then document that the DICOM queue recovered.

If failures continue, proceed with network and destination checks.

Confirm the Correct Destination Is Selected

Verify that images are being sent to the intended PACS, archive, or routing destination.

Action:

Expected outcome: The image transfer destination is appropriate for the exam workflow.

If the wrong destination was selected, correct the workflow, resend the images if appropriate, and stop if the issue is resolved.

Check Modality Worklist Query Behavior

If the issue is missing or unavailable worklist exams, verify the query conditions.

Action:

Expected outcome: You determine whether the order is missing from the source system or blocked by a query/filter mismatch.

Why it matters: Many “worklist not working” calls are caused by scheduling, order status, department mismatch, or overly narrow search filters.

If the order appears after correcting filters, stop and document the workflow correction.

Verify Patient and Exam Data

Check whether images are failing because of incomplete or incorrect exam information.

Action:

Expected outcome: Patient and exam data are complete enough for the PACS/RIS workflow.

Why it matters: PACS or routing rules may reject studies with missing accession numbers, wrong modality data, or mismatched patient identifiers.

Confirm Network Settings Were Not Recently Changed

Ask whether any known changes occurred before the issue started.

Action:

Expected outcome: You identify whether the failure began after a known IT or PACS change.

Why it matters: DICOM communication depends on matching network parameters between the modality and the receiving system. A server-side change can make a previously working system fail.

Restart the Application or Workstation if Safe

If no patient is active and local policy allows, perform a controlled restart.

Action:

Expected outcome: Temporary application or communication lockup clears.

If communication returns after restart, monitor the queue and document the recovery.

Test with a Known-Good Workflow

Use a controlled test to separate system failure from order/workflow issues.

Action:

Expected outcome: The system either communicates normally with a valid workflow or continues to fail despite correct setup.

Why it matters: A known-good test prevents chasing a problem caused by one bad order, one failed study, or one incorrect destination.

Escalate to PACS/IT When External Network Causes Are Likely

If the system appears functional but cannot communicate, involve the correct support group.

Action:

Expected outcome: PACS/IT can check server logs, firewall rules, routing, switch status, and destination availability.

Why it matters: Clinical Engineering can verify the device-side basics, but PACS/RIS/server-side failures usually require IT or imaging informatics support.

Do Not Change DICOM Configuration Without Approval

Avoid making configuration changes unless authorized and documented.

Action:

Expected outcome: The system configuration remains controlled and traceable.

Why it matters: Incorrect DICOM changes can break routing, cause patient data issues, or affect multiple downstream systems.

If the Problem Persists

If power, login state, network cabling, wall jack status, queue behavior, destination selection, worklist filters, patient demographics, and known PACS/IT issues have been checked, then external room-level, workflow, and basic network causes have been ruled out. The likely cause may be an internal workstation software issue, network adapter issue, DICOM configuration problem, or server-side integration failure.

The Ysio Max should be removed from clinical use if images cannot be safely stored, transferred, or associated with the correct patient record. The system should be labeled Out of Service if normal imaging workflow cannot be maintained and sent for repair, bench evaluation, Siemens service, PACS support, or IT/network support as appropriate.

Knowing when to stop is proper troubleshooting. Do not perform deep software reconfiguration, unsupported network changes, or internal workstation repair without authorization.

Clinical Use Tip

Do not troubleshoot communication failures during an active patient exam if it delays care. Move the patient to a backup device or another imaging room first if therapy continuity or imaging workflow cannot be maintained. Complete the exam safely, use the approved downtime process, verify images are stored locally if possible, and move to another imaging room if PACS or worklist communication cannot be restored quickly.

Work Order Documentation (CCR Method)

CCR = Complaint, Cause, Resolution

Complaint

What was reported by the clinical staff.

Example:
"Radiology reported the Siemens Ysio Max could acquire images, but DICOM sends were failing and the Modality Worklist was not updating."

Cause

What was observed during troubleshooting.

Example:
"Found the system connected to an inactive network wall jack after the room network cable had been moved during cleaning."

Resolution

What action was taken.

Example:
"Reconnected the Ysio Max to the correct active network jack, confirmed worklist query returned scheduled exams, resent queued images to PACS, and returned the room to service."

Helpful Details to Include (If Known)

Final Thought

Ysio Max communication troubleshooting should follow a logical path: protect patient care first, verify the reported failure, check external network and workflow causes, then involve PACS, IT, or Siemens service when the issue is no longer device-accessory or room-level. Good documentation is especially important because DICOM and worklist problems often cross Clinical Engineering, Radiology, PACS, and IT responsibilities.

That is successful troubleshooting.

Related Guides

Was this guide helpful?

Don't see a guide you need?

Suggest a Guide