Loading problems between WS and Gateway

[hilario]

We have begin to upload studies from an Efilm station to the OnePacsGateway.
For some reasons, Efilm stop transfering information and abort transfer.
When we retry it seams Efilm check images are on the server and don't try to reload again.

What is the security of the DICOM transfer between a Station (either onepacs workstation, either efilm) and the gateway.
That means, what happend if the communication is broken for any reason? Does the tranfer restart when comms are restablished? Is there any probability that informations/images are corrupted?
Is it as secure as FTP?

[justin]

Hilario,

There is no security between EFilm (or any SCU) and the Gateway when you're sending studies. It uses DICOM on a standard tcp/ip connection. It is assumed that your Gateway will either be on the same local network as the storing SCU or that you create a VPN to send through. This is because many sending devices do not support DICOM over SSL. For an inexpensive/free solution I recommend using Hamachi for a secure VPN.

Of course, outbound DICOM to the OnePacs Central Server is done securely via SSL.

Retryability would be a property of your SCU (DICOM sender, eFilm in this case) rather than the Gateway. Many products will just re-attempt to send the entire study if the connection is interrupted. If the connection is interrupted the Gateway will discard any partially transmitted images. There is no risk of OnePacs Gateway corrupting them. We also perform an MD5 check to verify that the streamed image matches the image stored to disk.

Are these particularily large studies or are you sending over a slow connection? If so, we may need to adjust some of the DICOM timeouts in the Gatway.

If you can send me the Gateway log during a time of failure I could take a look.

Thanks,

Justin

[hilario]

Surely this is a line Speed/Quality problem. How can I solve this?
The log is too big. What do I have to look into the log in order to check this kind of problems or to send you just the relevant part?
Thanks

[justin]

Hilario,

Each line in the log file begins with a timestamp. So if you can send just the time in which the error occurs that would probably be sufficient. Otherwise just zip and email server.log. I think it's only 10mb or so.

Thanks,

Justin

[hilario]

Can you tell me anyway what do I have to do for slow links
.....
No answer on this issue??
Regards

[hilario]

Hello Justin. Can you recomend me how to improve working with low speed lines?
Regards

[justin]

Hilario,

I would need to see your log file to give you a specific recommendation on the problem. If it's a matter of timeouts then we can simply increase them. However, the defaults are set such that it allows for about 10 minutes for a single dicom object to store before a timeout occurs. Unless you are sending very large objects this is unlikely.

If it's a matter of the connection being interrupted then it's more an an issue with the sender. You would need to configure your sending device to not resend all the images for a single study/series because of a single failure. Basically, it should just resend the images that haven't been successfully acknowledged by the SCP (the gateway).

Thanks,

Justin

[justin]

Also, the most obvious solution would be to improve the speed of the network connection.

Justin

[hilario]

Basically I understand. I will send you by mail the log file. mail will arrive from hilario.martinez@gmail.com (for your spam filter).

You should find different kind of errors from tests I did today
- Two different PACS (efilm) tried to load studies on my gateway:
--- One say tranfer OK but I could find the studies (I wonder if they are sending to another place) this has been aroung 16:00 o later on our time
--- One doesn't start the transfer (this has been around ) 13:00 our time

- I have also seen strange behaviour on OnePac WEB:
--- Certain studies seams to have finish the transfer (there is "arrive time") but there are very few images...
--- Some minutes later "arrive time" is blanck and more images are arriving
Supose this is speed problem on the line (we are waiting for an upgrade) but durign this tiem we have to live with slow speed..

About the options of not resending images beeing previously sent...
How do you configure this on OnePacsDesktop?
Do you know how to configure this on EFILM?

[justin]

Hilario,

For slow systems you can increase the value of the worklist timer for facilities that exhibit this behavior (Admin -> Facilities). Setting a timer of 5 minutes or so means that the server will wait 5 minutes from the time the last image was received before moving the study from "In transmission" to "Ready to Read". This is useful for systems that may have a long pause between series.

I'm not sure if eFilm has an option to not resend images that it has already sent successfully. However, from the logs I noticed that it does a C-FIND immediately before performing the C-STORE. Presumably, it's checking to see if the study exists before re-storing it.

Another thing I noticed is that your sender uses 4 consurrent asychronous associations. This means that system and network resources are split 4 ways when C-STOREing. If you have a slow connection, this may not be ideal and you may want to single thread it. There should be a configuration option in eFilm for this.

OnePacs Workstation does not maintain state of failed transmissions and thus does not have the option to only resend the unsent images.

Thanks,

Justin