Posts by skrani

    Hello Sundar.


    When querying for the "removed" PID folders you will just get errors in serverstatus log. (no other effect that I know of)


    You will not corrupt your database as far as I know.


    If you put the images back (with proper privileges) then you can retrive them.


    Good luck


    Steini.

    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.

    Hello All.


    I occationally get this message on one of my Conquest servers.
    (Yeah I have installed many. Conquest is absolutely great, it can be used for all sorts of "hot fixes" as well as nice archives. We use conquest a lot as DICOM Storage SCP for research software that generally has bad or no DICOM storage SCP, or to achieve "special effects" (with input converters) for viewers such as K-PACS)


    The message is:
    ZipMsgXX.res is probably not linked to the executable.
    Missing String ID is: 11001


    Then there vill be file called ZipTmp??.??? (where ? is wildchar, example of file name is ZipTmp0g.t00)
    There will be a Zip file as well with exact same timestamp and size (at 5 in the morning)
    This does not happen every night, sometimes several days will pass, sometimes every night.
    Conquest version is 1.4.14
    Windows Server 64bit R2.


    I cant see that this effects the server in any bad way, it keeps running.
    (well actually it uses up 100% cpu power eventually, but I can not see any connection to this message)


    Best regards
    steini.

    Hello Marcel.


    There is NO line that I could find the last 3 days in serverstatus that says "hi"


    I tryed the sysinternals process explorer, but I need some instructions on how to use it :-)


    Below is my dicom.ini


    (I discovered that I had debugging turned on, if that makes any difference, I will let you know)


    Code
    # This file contains configuration information for the DICOM server# Do not edit unless you know what you are doing[sscscp]MicroPACS = sscscpEdition = Personal# Network configuration: server name and TCP/IP port#MyACRNema = ICSREMOTEBACKUPTCPPort = 5678# Reference to other files: known dicom servers; database layout; sopsACRNemaMap = acrnema.mapkFactorFile = dicom.sqlSOPClassList = dgatesop.lst# Host(ignored), name, username and password for ODBC data source# SQLHost = localhost# SQLServer = MFP_conquest# Username = xyz# Password = xyz# DoubleBackSlashToDB = 1# UseEscapeStringConstants = 0# Host, database, username and password for MySql databaseSQLHost = localhostSQLServer = conquestUsername = xyzPassword = xyzMySql = 1DoubleBackSlashToDB = 1UseEscapeStringConstants = 0# Configure databaseTruncateFieldNames = 10MaxFieldLength = 254MaxFileNameLength = 255FixPhilips = 0FixKodak = 0KeepAlive = 60LargeFileSizeKB = 16384PrintSquareLandscape = 0ZipTime = 05:UIDPrefix = 1.2.826.0.1.3680043.2.135.733381.56617265EnableReadAheadThread = 1PatientQuerySortOrder = StudyQuerySortOrder = SeriesQuerySortOrder = ImageQuerySortOrder = EnableComputedFields = 0IndexDBF = 1PackDBF = 0LongQueryDBF = 1000TCPIPTimeOut = 300FailHoldOff = 60RetryDelay = 100QueueSize = 128WorkListMode = 0WorkListReturnsISO_IR_100 = 1DebugLevel = 0Prefetcher = 0LRUSort = AllowTruncate = DecompressNon16BitsJpeg = 1UseBuiltInDecompressor = 1IgnoreOutOfMemoryErrors = 0PadAEWithZeros = 0FileNameSyntax = 3# Configuration of compression for incoming images and archivalDroppedFileCompression = n4IncomingCompression = n4ArchiveCompression = as# Names of the database tablesPatientTableName = DICOMPatientsStudyTableName = DICOMStudiesSeriesTableName = DICOMSeriesImageTableName = DICOMImagesDMarkTableName = DICOMAccessUpdatesRegisteredMOPDeviceTable = RegisteredMOPIDsUIDToMOPIDTable = UIDToMOPIDUIDToCDRIDTable = UIDToCDRID# Banner and host for debug informationPACSName = ICSREMOTEBACKUPOperatorConsole = 127.0.0.1# Configure email of error messagesMailHost =MailPort = smtp MailSignon = MailFromName = MailRcptName1 = MailCollectTime = 1MailWaitTime = 10# Configuration of disk(s) to store imagesMAGDeviceThreshhold = 0MAGDevices = 2MAGDevice0 = F:\DICOM_MAG0\MAGDevice1 = G:\DICOM_MAG1\NightlyCleanThreshhold = 0



    And I added "loads" of "columns" to this server that only needs few hours to get to 100% cpu time.
    (I needed some DICOM tags into the database.)
    On the server that needs longer to reach 100% cpu time (some weeks) I only added 3 or 4 lines to DICOM.SQL (for e-Film)
    My modified DICOM.SQL is here below.





    Best regards


    steini.

    I have been experiencing the same thing after upgrading to 1.4.14, and it also happens in 1.4.15alpha.


    In both cases I am running on 64 bit windows on 8 cpu machine, it starts taking fully 2 cores, then 4, then 6 and finally all 8 cores.


    I have not run older versions on the 64 bit windows server, and am not experiencing this on older 32 bit windows conquest 1.4.13.
    (Changed the server and conquest version at the same time)


    This happens on 2 sites, on one of the sites, within 48 hours all 8 cores will be fully loaded. On the other site it takes weeks.


    Best regards


    steini, service engineer Iceland.

    Hello again.


    Kept thinking a little, it could actually be nice to have this as an option, so when conquest recieves images, it would anonymize them on store.


    Then you could have option on transmitt to "restore" real patient id's (maybe per known dicom providers)


    (The research institude we work for occationally has to send images out with real patient names, (if the participants are actually sick))


    Just dreaming up all sorts of things....


    Best regards


    steini.

    Hello Marcel.


    My company works for a research institude and there they have decided to create "customer number" for all their customers.
    So in theory, there is a master database with proper personal ID and this "customer number"


    When the "patient" is taken for examination the proper "patient names", age etc.. and this "customer number" is fed through MWM and used during the Patients visit. It was deemed nessecary to have the real name during patients visit to reduce risk of "patient mixup"


    Then when images are sent from the modality, they are sent to a "id remove" workstation that copyes the "customer number" over the patients name, patient age and sex is left as is, but birthdate is changed to 1 jan on the birth year and address etc is removed.


    After this there is no way to connect the data to a specific person, unless you have the Master database to link the images to patient.
    You still have the patients age and sex, that can be relevant for scientific research.


    Similar could be done in many ways, such as adding a "decode" table to conquest, so when you anonymize a patient, the real name and ID would be put into this table, along with a "number" that would be used to overwrite the name and ID on the images.


    Hope this helps.


    Best regards
    Steini

    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.

    Could you post the error here?


    And possibly parts of the server status file from the time you try to retrieve the patients.


    Good luck.

    Hello Marcel.


    They dont make it easy to submit bug reports :(


    Their forum looks as if noone ever looks at it.
    The knowledgebase last "post" is from april 2007


    The only thing easy to access is the online shop !


    I am trying to register on their forum and will post my findings there for fun, and monitor if something happens.


    Nice to know that you read the posts here. :)


    Conquest is great software! Thanks for your hard work.

    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.

    Hello All.


    I have weird problem, just wondering if anyone had experienced it.


    I just upgraded efilm from 2.1.2 to 3.0.1 and after that I do not get the complete list of patient when query-ing Conquest. (usually only one is displayed, even though the match is much higher)


    For example when I query today I just get one patient, even though there are lots of them...
    (Conquest log ,reports correct number of found matches)


    Any Ideas??


    Thanks in Adwance.


    steini.

    In your dicom.ini file in the conquest folder there are lines for the database access. Now the database name is set to conquestpacs_s2 and username and password set to conquest. (sounds like default settings for second conquest to me....)


    If you set up ODBC source you should name it conquestpacs_s2 or change that line in your dicom.ini file to what ever ODBC name you select.


    I personally would change the ODBC name and Dicom.ini to something more descriptive, also if there is a ODBC connection called Xray or something, just change the dicom.ini file to point to that ODBC.


    JUST MAKE SURE you dont use the same ODBC connection as the CTSCAN part.


    good luck.

    Is JPEG transfer enabled in dgatesop.lst.


    You might want to try to disable all transfers except LittleEndianImplicit for testing purposes.


    Just a thought.

    You will also get similar messages (do not remember exactly how they are) if you are using MSDE or MS SQL express, (The free SQL server editions from Microsoft) when they have reached their limits.


    MSDE database size limit is 2GB, but 4GB limit is on MS SQL express edition.


    At least this is a problem with your SQL server.


    The 2 errors are "the same problem" it can not save to SQL because it is full.


    Good luck.