E-FILM Did Not Accept The Connection

    Hello


    This is an odd issue that I get from time to time between E-FILM and Conquest for MRI studies. At odd times E-FILM cannot retrieve the MRI studies. Conquest reports that the e-FILM did not accept the connection. If I try and forward the MR study from Conquest -> e-FILM the same happens.


    At other times it works fine.


    Any clues why this happens ?


    Louis

    Hi,


    Is it reproducible for certain patients or studies? It might be an issue with a non-recognized modality (e.g., 3D MRI). You might try to send images one by one or sort by sort and see where the issue lies.


    Marcel

    It is happening with pretty much any MR studies. I have tried moving one image by one, and the issue remains to E-FILM. However sending the MR studies to another conquest server works OK.


    Louis

    Hello Louis.


    I am assuming you have e-Film 3.0


    I had problems with e-Film 3.0 and Conquest, and posted my problem and "solution" here some weeks ago
    See "short story" below, you may have similar problems.


    Try to see if any dicom tag is not filled out from your MRI and filled out from other modalities that do not cause this problem.
    See if you can do some tricks to fill them out with fixed data like I did.


    Good luck.


    Regards
    steini.


    efilm 3.0 Gold - does not display list of patients.
    by skrani on Tue Mar 04, 2008 2:05 am


    .............................
    After a while I found out that e-Film 3.0 will not properly display query result if the field StudyID is missing. some of the modalities at the site I did the upgrade on e-Film at, do not send anything in the StudyID DICOM tag, and that "confused" e-Film 3.0 somehow.


    To "solve" this I modified the MySQL database a little.


    First did a count on how many studies have nothing in the studyID:
    select count(*) FROM `conquest`.`dicomstudies` where StudyID is null


    Then added "studyID" of my own. (dummy one, checked the affected rows against the count above):
    update `conquest`.`dicomstudies`
    set StudyID = 'steini123'
    where StudyID is null


    And finally, changed the table so it would have default value if nothing is sent:
    ALTER TABLE `conquest`.`dicomstudies` MODIFY COLUMN `StudyID` VARCHAR(16) CHARACTER SET latin1 COLLATE latin1_swedish_ci DEFAULT 'steini123';


    This way, when Conquest is queried it will return something in the StudyID.
    I considered using Importconverters, but that would permanently change the images, and I was not to confortable with that idea.

    Hi Steini


    I am on E-FILM Version 2.0. Thank you for the solution. Unfortunately if appears that this is not my issue, I did a check on the study UID for all the MR studies and none of them are null. So my issue is something else. It would help if E-FILM logs gave a bit more information when Conquest is trying to send the data to it.


    I have encountered this issue before with E-FILM, but in this particular case E-FILM was not accepting any data because the water mark levels was too high, and when the PC was close to disk full, E-FILM would not accept any studies, and Conquest kept giving the above error. The fix was to lower the water marks levels to a reasonable level.


    If others have other ideas, by all means let me know.


    Will keep debugging this.


    Louis

    This issue is also apparent if I use K-PACS to retrieve the studies. A packet sniffer shows checksum errors. I am trying DCMTK C-MOVE to see if it reveals any useful information. Prior to a certain date this was not an issue for us. I also see no networking issues on the port, AE allocated as other modalities works fine for retrieval using efilm. At this stage I am suspecting a change that the modality may have done that is causing this grief.


    It does not appear to be a Conquest problem, at this stage anyway.


    Louis

    I've also burnt a study that gives this error on a CD, and efilm opens it with no issues from the CD. So does not appear to have incompactible dicom conformance that efilm does not understand for these studies.

    Have contacted the vendor, and this is a possible explanation from them for this issue. "Achieva" is the MR modality source.



    As far as I know Conquest does not stip off any header information.


    How can I check if studies are being received as pure dicom images in Conquest ? What header attributes distinguishes that ?


    Louis

    I have an update on this matter, as I've made some progress.


    The modality sends studies to Conquest as a single frame per series. We have another reporting station that receives studies from the same modality, and stores them as multiple frames per series. When I send the studies off the reporting station to Conquest which it then stores as multi frame per series, and then try a retrieve from E-FILM off Conquest, I can FINALLY retrieve the studies.


    Is there any particular difference between multi frame, and single frame series DICOM other than the fact that a multi frame series sends a header per each image stored in the series, while the single frame just sends a single header on a bigger single image series study ?


    Thank You


    Louis

    Hi,


    efilm may not work with multi-frame objects - for conquest it is all the same - it stores and retrives just as well a single object as multiple small objects. Conquest will not modify the data in any way. You can force the scanner to send multiple objects by removing the corresponding SOP for multi-frame from dgateasop.lst. The only issue with multi-frame may be its size. Conquest chokes on objects exceeding 500 MB or so.


    Marcel

    I have made a post at eFilm forum about that. I suspect then KPACS has the same issue as I experienced the same problem when trying to retrieve off Conquest. I will leave the setting in the lst file at Conquest as I've asked the modality to send us multiple objects instead, which they were doing before prior to a software re-configuration that was done by them from the time we noticed this issue.

    Quote


    You can force the scanner to send multiple objects by removing the corresponding SOP for multi-frame from dgateasop.lst


    Isn't Enhanced MR Image Storage multi frame, and MR Image Storage single frame. If I remove / comment this


    MRImageStorageEnhanced 1.2.840.10008.5.1.4.1.1.4.1 sop


    as stated above from dgatesop.lst, how does that force a multi frame sending from Scanner ?


    I have however done what you said, and it forced multi frame sending from scanner. However I am unclear about the above comment.


    Please elaborate why this is so.


    Thank You


    Louis

    Hi,


    assuming that the scanner can choose, by removing one of the options from conquest, it will force the scanner to choose the other one. So if you do not like multiframe, disable MRImageStorageEnhanced and the scanner should send "clasic MRI". Wether this works depends on the scanner though.


    Marcel

    Forgot to add the the scanner does choose between the two formats. It's test showed that Conquest supports both formats. However having both uncommented in dgatesop.lst kept forcing the scanner to send single frame SOP. It only forced multi frame SOP after multi frame SOP is commented in dgatesop.lst.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login