PacsOne Server

Hello All,

I've been playing with the latest EFilm V2.1 and am able to query Pacsone and pull studies back to my PC. I am able to view MRI studies and CT scouts, but most CT images fail to load under EFilm. US also has the same issue.

EFilm's forum just points me to their conformance statement.

I am able to pull or push studies from our GE workstation just fine and the same images do work.

I posted on EFilms forum and someone else had the same issue with a different PACs so I don't think it's a PacsOne issue.

Just a heads up for anyone else thinking of using EFilm as a workstation.

Jeff

Thanks, Jeff, for sharing this information with the forum.

1. Is this a free trial version of eFilm? If so, do they have a sales contact who can field this sort of issues?

2. What about earlier versions of eFilm? Do you have similar issues with earlier versions?

There is a 30 day trial version. I did not call their support line, but did use the online forum. The forum was fairly responsive, but didn't seem to have any suggestions beyond looking at their conformance statement.

Someone mentioned that an earlier version had the same issue, but I didn't try anything but the most current.

Jeff

I cannot believe they won't help you out with the problem, as this won't help to convert the trial into a sale.

Maybe you can try this:

Pick a sample image which the new eFilm fails to load, call their sales number (maybe a regional sales office) to try to get someone to visit your site, since most sales people travel with support engineers, you should have better luck having your problem solved by the field support engineers versus calling their support line. But this may depend on how many eFilm licenses you have purchased or are likely to purchase.

Anonymous wrote:Hello All,

I've been playing with the latest EFilm V2.1 and am able to query Pacsone and pull studies back to my PC. I am able to view MRI studies and CT scouts, but most CT images fail to load under EFilm. US also has the same issue.

EFilm's forum just points me to their conformance statement.

I am able to pull or push studies from our GE workstation just fine and the same images do work.

I posted on EFilms forum and someone else had the same issue with a different PACs so I don't think it's a PacsOne issue.

Just a heads up for anyone else thinking of using EFilm as a workstation.

Jeff

hi,

I have tried eFilm 2.0 with pacsone in linux
and it works smoothly.

What CT scanner do you use? We use GE. They keep wanting me to compare conformance statements. While this may confim a compatibility problem it will not fix anything. I am able to pull MRI images off PacsOne and it works fine. Some CT images even display (i.e. scouts), but most error.

Here is a link to the forum discussion:
http://forums.merge-efilm.com/efws/viewtopic.php?t=595

Jeff

I think what eFilm wants you to do is to examine the Dicom conformance statement of your GE CT scanner, specifically the list of storage SOP classes it supports for the images created by the CT scanner. Then check that list against the Dicom conformance statement of eFilm, make sure every storage SOP class on that list is supported by efilm.

If that's the case, I think you can take a sample of these CT images which eFilm would not display, and question their conformance. Based on your description about some CT images are actually displayed successfully, it seems that eFilm was having trouble with some data elements in some of the images, instead of not supporting a particular CT storage SOP class.

I am able to push or pull images from our GE workstation to EFilm and they work fine. When those images are pulled from PacsOne they produce an error. PacsOne syncs hourly with our GE workstation so it's the same study.

Jeff

This starts to ring a bell as it reminds me of a known eFilm issue where it does not support the Dicom Explicit VR Little-Endian transfer syntax, but yet some versions of eFilm actually does accept (instead of reject) images encoded in Explicit VR Little-Endian transfer synax and then silently fails to receive them.

You can try the following to verify if this is the same problem or not. Add a string value to the PacsOne registry:
set the string value to be 1.2.840.10008.1.2. Restart PacsOne Server and send a few new images from the GE CT sccanner to PacsOne, and have eFilm pull the new images. If eFilm can pull the new images with the above registry change, then the problem is with eFilm receiving Explicit VR Little-Endian transfer syntax encoded images converted into the default Implicit VR Little-Endian transfer synax, most likely because of the private data elements generated by the GE CT scanner.

Adding the registy setting won't interfere/hurt anything down the road? I can always delete and resync the studies later if needed.

Jeff

This registry change will make PacsOne always pick the Implicit VR Little-Endian transfer syntax, thus no conversion will be necessary when PacsOne sends the images to eFilm. The side effect of adding this setting is images received by PacsOne will not be compressed, even if the input modalities support compression.

So if you are not using any compressions at your site, this new setting will be fine. Otherwise, we will need to figure out which data element was causing eFilm to fail when the images were converted from the Explicit VR to Implicit VR Little-Endian transfer syntax. You can download a sample of such images into a ZIP file and send it to mailto:pacsone@pacsone.net, and we can test it with an older eFilm version to see if it can receive it.

That fixed it. I retirieved a fresh study after the hourly sync and was able to view it fine under EFilm. Compression should not be a problem now, but I don't know about the future. We just added a new Ultrasound which has compression for the cardiac stuff, but our workstation chokes on those too.

There's no way to switch the endian-ness on the Tx instead of the Rx?

BTW, good job troubleshooting.

Jeff

Anonymous wrote: There's no way to switch the endian-ness on the Tx instead of the Rx?

On the Tx, it is the receiver (eFilm) that gets to pick whether to use the Explicit or Implicit VR transfer syntax, so even if the sender (PacsOne) presents both choices: Explicit and Implicit VR Little-Endian transfer syntax, it will be up to the receiver (eFilm) to decide which one to use for the transfer. If eFilm picks the Explicit VR transfer syntax but does not really support it, then there is nothing we can do from the sender side.

Maybe we should have a web interface option to chose the transfer syntax for a specific AET?
Thus we can single out all our Efilm AET's and just use the Implicit VR Little-Endian transfer syntax.

Damn Efilm!!! Good application thou.

I think same issue with me for Efilm, I have added the string but is the String value 1.2.840.10008.1.2. (period at the end) or 1.2.840.10008.1.2 (no period at the end).