Conquest features

  • Greetings.


    We'd like to set up an own DICOM server for our researches in a 3T MRI environment.
    The institute has it's own DICOM server and backup solution, but research data is not allowed to be
    sent on the CELSIUS server, due to it's size.


    That's why we'd like to set up our own DICOM server in the post-processing room.
    I found Conquest as a free solution, and I'm really glad for it.


    I have a few questions:


    Does it accept spectroscopy data too?
    Is it possible to recieve data from Siemens Leonardo Workstation?
    Is there a size limit for the database?
    What op. system do you prefer/recommend


    Actually a few TB would be enough for us.
    I was thinknig in a RAID 5 array of 4pcs of 1TB HDDs.



    Any help would be appreciated.


    Thank you

  • Hello Grisha.


    I can really reccomend Conquest as Reasearch database.


    For example you can modify DICOM.SQL to get what you want from the DICOM headers to the database.
    (just make sure you add what you want in the middle of the sections (leave first and last line of patient, study, series and image as they are))
    (NOTE ! You will need to rebuild database if you make changes on running system)


    Conquest has accepted anything I want so far, I would expect it to accept your spectroscopy images as well.
    (see dgatesop.lst where this is one of the supported SOP
    MRStorageSpectroscopy 1.2.840.10008.5.1.4.1.1.4.2 sop)


    I have used it with Siemens Leonardo without problems.


    "The sky is the limit" for the database.. Your 4TB will not be a problem. I reccomend using MySQL as database.


    I prefer Windows 2K3 server. We have used XP in the past with good results as well. (a lot cheaper)


    Happy Conquest-ing.
    steini.

  • Hi.



    I've just set up the DICOM server. It was quite easy. Syngo needed to be modified a bit, but it was quick and clear.
    It works flawlessly, and fast with mysql.


    But, unfortunatly, it doesn't accept MRS data. :(


    I've read a post this is it:


    "I am now trying to fight the following problem around Conquest.
    A Philips MR scanner is able to produce some private dicom objects,
    e.g. MR spectra, identified by private SOP classes. If these SOP
    classes are added to Conquest configuration dgatesop.lst file,
    store/query/retrieve works fine from the Philips side."



    What should I add to dgatesop.lst in order to work, and be able to accept spectroscopy data?
    I'm not familiar with the SOP classes (don't even know what they are), so I think I should figure
    out what SOP classes are defined in the spectroscopy data and add it in dgatesop.lst. Easy to say, but don't know how
    to do.


    Could you help me?

  • Hi,


    the log file of the server shows the SOP class UID (20 digits or so) to be added. Then google this UID, find its official name and add it to dgatesop.lst in the same way as other image types are defined,


    e.g., CT is defined as:


    CTStorage 1.2.840.10008.5.1.4.1.1.2 sop


    thus add lines like:


    NameOfClass UIDofclass sop


    And then restart the server and try again.


    Marcel

  • Thx for the reply. Now conquest accepts
    spectroscopy data too.


    But we encountered another error, while sending huge study to the conquest server (with multiply modality scans MRS, MRI, DWI) 4-6000 scans, sometimes it
    does not finish recieving the file-s. Sysngo sais transfer comleted, but the server haven't write: "Thread number ended at date ".


    Is it normal?


    Sometimes it writes that Thread ended, sometimes it doesn't.


    Actually, we've just tested with 194 scan VBM studies, and it failed to write: "Thread number ended at date "
    2 times out of 8.

  • Hi.


    So I've just managed to log two events, when the thread does not end.
    Attaching the serverstatus log and screenshots.


    2009.05.14. 10:41:08 the first transmission started
    ....
    2009.05.14. 10:45:43 the first thread ended, no THREAD ENDED AT... line


    2009.05.14. 10:53:30 the second transmission started
    .....


    2009.05.14. 10:58:13 the second thread ended, no THREAD ENDED AT... line



    You can find many other normal threads in the same log like the first one:



    Normal transaction:
    2009.05.14. 8:40:01 [KUTARCH] UPACS THREAD 2: STARTED AT: Thu May 14 08:40:01 2009
    2009.05.14. 8:40:01 [KUTARCH] Calling Application Title : "LEO2710 "
    2009.05.14. 8:40:01 [KUTARCH] Called Application Title : "KUTARCH
    .....
    2009.05.14. 8:40:27 [KUTARCH] UPACS THREAD 2: ENDED AT: Thu May 14 08:40:27 2009
    2009.05.14. 8:40:27 [KUTARCH] UPACS THREAD 2: TOTAL RUNNING TIME: 26 SECONDS



    The CPU usage is normal after the threads, even if it was not closed.


    By the way Leonardo workstation sais the transfer is completed without errors, and the study appears in the database browser.


    Actually I can't upload attachment. so i put it on humyo and made them public.


    http://www.humyo.com/F/7891739-579163833


    http://www.humyo.com/F/7891739-579164135


    http://www.humyo.com/F/7891739-579164225

  • Hi Grisha,


    I believe the error is only in logging. If the GUI cannot keep up with server, it loses lines. You can try to install as service and close the GUI. And then inspect the log files again after performing a few such transactions. If the GUI is closed, the server logs directly to file and cannot lose any lines.


    Marcel

  • If it's only that, than I won't care. So far it accepted and stored all the data we sent on it, so I can live with this bug.
    We uses the gui quite often, for sending patient data back to several worstations, and so.


    Thx for the help.

  • Hi Marcel!



    Could you recommend an application that can accept studies sent by the conquest server under linux (Fedora core 10).


    We'd like to transfer studies from the conquest server to post-processing workstations for evaluation with FSL, LCModel, Matlab, etc.

Participate now!

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