Saturday, February 04, 2012
Google Custom Search

ClearCanvas Highlights

Download our  Software
Watch some Videos
Get the Source
Check out our Licensing
Join our  Forums
Some Research: OICR IPP-Trials

Product Bulletin 005 - 2011-07-04

What product is affected?

  • ClearCanvas ImageServer v.2.0 of the ClearCanvas RIS/PACS v.2.0
  • ClearCanvas ImageServer v.1.5 of the ClearCanvas RIS/PACS v.1.5
  • ClearCanvas Workstation v.2.0 SP1 of the ClearCanvas RIS/PACS v.2.0
  • ClearCanvas Workstation v.2.0 of the ClearCanvas RIS/PACS v.2.0
  • ClearCanvas Workstation v.1.5 SP1 of the ClearCanvas RIS/PACS v.1.5
  • ClearCanvas Workstation v.1.5 of the ClearCanvas RIS/PACS v.1.5

When using ClearCanvas Workstation, if a user initiates a retrieval of a study from a ClearCanvas ImageServer, or another Workstation, it is possible for the retrieve operation to fail silently without any errors or warnings indicated in the Workstation’s Receive Queue. This may result in the user assuming a complete study has been received when images are missing.

What is the scope of this issue?

In DICOM, the application that initiated the retrieval of a study (e.g. Workstation) is normally updated by the server (e.g. ImageServer) with progress information, including the total number of files/images to be transferred and the number of failures, etc.

Although there are a few ways it can happen, the problem generally manifests when the network is slow or congested and the server stops sending files due to a timeout condition. In this situation, the server is supposed to send a final progress update to the client indicating the number of files in the study that were not successfully sent. Both the ImageServer and Workstation, when sending files to another device in response to a retrieve request, fail to send this final progress update when an error occurs in sending. Because the Workstation does not receive this progress update, it is unable to determine that any errors have occurred, and hence cannot show an error message in the Receive Queue.

This same timeout situation can occur when a send operation is initiated from the ImageServer, either manually or via an auto-routing rule. However, in this situation, there is nothing any PACS workstation can do to alert a user that a study was not completely received, due to limitations in DICOM. Your PACS administrator should be actively monitoring the ImageServer’s Work Queue for failures. If an error occurs, the Work Queue item will indicate the reason for the failure.

Have people actually been affected by this issue?

The issue has been reported by a number of users on our forums. To our knowledge, everyone has been able to resolve the issue by increasing certain timeout settings in the ImageServer and/or Workstation configuration files.

What do I need to do?

  • Assess whether or not this problem is occurring at your institution. If you have a reasonably fast, reliable network, this problem may never occur. To check if this problem is occurring on your ImageServer, go to Admin/Application Log, enter "DIMSE timeout" in the Message field, and execute the search. You can also check the Workstation logs for the same text. Note that both the ImageServer and Workstation logs may only go back a short period of time as they are purged or roll over regularly.
  • For all ImageServer and Workstation installations, Increase the DICOM read/write timeouts to a number that is reasonable for your network. If it is increased to an unreasonably high value, you may have problems with connections that never close. A guideline for the value to enter would be the maximum amount of time you would be willing to wait for a single image to transfer before suspecting something is wrong. Take into account very large images, like multi-frame ultrasounds, Enhanced MR/CT, or even large mammograms and x-rays, if you have modalities that produces such images.


    To adjust the timeout settings for the ImageServer:

    • look in the installation directory for a file whose name ends with ShredHostService.exe.config and open it in a text editor, like Notepad
    • Find the settings group ClearCanvas.Dicom.Network.NetworkSettings
    • Change the values for the ReadTimeout and WriteTimeout and save the file (setting values are in milliseconds)
    • Restart the ImageServer Shred Host Service (via Control Panel > Administrative Tools > Services)


    If you have a cluster of ImageServers, you will need to do this on each machine.

    To adjust the timeout settings for the Workstation:

    • Follow the same steps as for the ImageServer, but you will likely need to first paste the settings into the config file because they are not there by default. A sample configuration file is included at the end of the document with the relevant sections highlighted.
    • Restart the Workstation Shred Host Service (via Control Panel > Administrative Tools > Services)
    • Most importantly, when you retrieve a study to the Workstation, or are about to open one that has been auto-routed, always perform a simple comparison of the number of images received to the number on the source server. The column labeled “Instances” in the Workstation’s DICOM Explorer gives you this information. You will need to find the study locally ("My Studies") and on the source server in order to compare.

What is ClearCanvas doing to address this issue?

We have already made a change in our DICOM toolkit that fixes the problem in both the Workstation and ImageServer products. Note that, in order to ensure an error message appears in the Workstation’s Receive Queue, you must upgrade both the Workstation and ImageServer products.

Also note that the information contained in this bulletin assumes you are using both the ImageServer and Workstation products. If you are using only one of the products, you will need to assess how this issue will affect your system as a whole. If you have specific questions, you can always email us at info@clearcanvas.ca or post a message on our user forums.

Corrective Action Timelines

The fix for the problem has been released in the ClearCanvas Workstation, Clinical Edition as well as the ClearCanvas PACS, Team Edition.

Sample Configuration File

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<section name="ClearCanvas.Dicom.Network.NetworkSettings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
</sectionGroup>
</configSections>
<applicationSettings>
<ClearCanvas.Dicom.Network.NetworkSettings>
<setting name="ReadTimeout" serializeAs="String">
<value>30000</value>
</setting>
<setting name="WriteTimeout" serializeAs="String">
<value>30000</value>
</setting>
<setting name="ConnectTimeout" serializeAs="String">
<value>10000</value>
</setting>
<setting name="ReceiveBufferSize" serializeAs="String">
<value>118341</value>
</setting>
<setting name="SendBufferSize" serializeAs="String">
<value>118341</value>
</setting>
<setting name="LocalMaxPduLength" serializeAs="String">
<value>116794</value>
</setting>
<setting name="RemoteMaxPduLength" serializeAs="String">
<value>116794</value>
</setting>
<setting name="DisableNagle" serializeAs="String">
<value>True</value>
</setting>
<setting name="CombineCommandDataPdu" serializeAs="String">
<value>True</value>
</setting>
</ClearCanvas.Dicom.Network.NetworkSettings>
</applicationSettings>
</configuration>

Product Bulletin 004 - 2010-06-18

Maximize

Product Bulletin 003 - 2010-06-18

Maximize

Product Bulletin 002 - 2010-02-05

Maximize

Product Bulletin 001 - 2009-09-11

Maximize
Copyright 2011 ClearCanvas Inc.