Posts by Flyboy

  • slow transfer speeds

    I have a strange issue I've been working on for a while and I can't figure out the problem, so I thought I would try here.
    I have 6 conquest servers set up, through 4 different locations.
    Whenever I go to transfer images between them, I only ever get 3Mbps on the transfer speeds.
    The servers are connected through VPN connections, but on fast lines.
    2 of them are on gigabit internet lines in 2 datacenters.


    When I test my vpn connections with any other traffic between those locations, I get a steady 250Mbps or higher (tested http, smb, ftp, ...)
    I even recreated my vpn's with all kind of different settings and encryption methods to see if any of them are more friendly towards the traffic conquest generates, but no luck.


    I also tested by installing a second instance of conquest on one of the servers, transfers between the 2 instances are instant, as you would expect. So it does not seem to be a conquest limitation.


    Has anyone experienced this before and might know of something that might be slowing down the connections, or what I could try to speed them up?


    Our conquest servers are all running windows, on HP proliant servers if that helps.


    dicom config:

  • Hipaa compliance

    Morning,


    One of our customers needs to buy all new hardware for all their pacs systems.
    The current hardware is aging and out of warranty now.


    While discussing the options with them they brought up the question if Conquest is hipaa compliant or not, and if not, if they would need to look into different PACS solutions.
    I can't really seem to find any info on whether or not Conquest is hipaa compliant, or what the requirements are for a PACS system to be compliant.
    Hipaa compliance is a requirement to get reimbursements from medicaid here.


    I hope there are some American users here that might be able to help out with that.


    Thanks,


    David

  • Change Patient ID number

    I inherited a multisite conquest system a while back, and have been upgrading and fixing minor issues since then.
    Now I think I stand in front of my biggest challenge.


    The current way patient ID's are generated can result sometimes in duplicate ID numbers being generated.
    We came up with a new way of assigning patient ID's but would like to change the old patient ID's to match the new ones, as not to confuse anyone here.


    I checked the manual and started looking at LUA scripts to see if there is something we can run on all images already in the database, but it doesn't look like it.
    Can someone confirm this?


    And if that doesn't work, my next thinking was to set up a second conquest instance, copy all images from the first to the second instance and make the necessary manipulations while copying.
    But then I'm also kinda unsure on how to create a list with the current patient ID's and the new ones and have conquest do the changes on the fly.


    Or use an external dicom editor to edit the images and then re-index?


    Any ideas or recommendations would be greatly appreciated.

  • Update 1.4.17c released

    It seems like the stops are unrelated to that message in the eventlogs.
    I just had multiple machine stop sending images halfway through a study, without the Client error message, and without anything in the pacstrouble log.


    The last version we had running is 1.4.17 beta3
    If I want to downgrade to that version again, do I copy the whole folder back or would the dgate files be enough?

  • Update 1.4.17c released

    I just had the error come up twice within 4 minutes on a server with debugging turned on.
    Below is a part of the log file
    If needed, Is there a secure way I can send anyone the complete log file?
    I don't really want to post it here since it contains patient data


    Code
    [NHCONQUEST1] 20131115 09:44:13 Connected by address: 0100007f[NHCONQUEST1] 20131115 09:44:13 Testing transfer: '1.2.840.10008.1.2' against list #0 = '1.2.840.10008.1.2'[NHCONQUEST1] 20131115 09:44:13 0000,0002     18 UI AffectedSOPClassUID    "1.2.840.10008.1.1" [NHCONQUEST1] 20131115 09:44:13 0000,0100      2 US CommandField           48 [NHCONQUEST1] 20131115 09:44:13 0000,0110      2 US MessageID              7 [NHCONQUEST1] 20131115 09:44:13 0000,0800      2 US DataSetType            257 [NHCONQUEST1] 20131115 09:44:13 0002,0010     17 UI TransferSyntaxUID      "1.2.840.10008.1.2" [NHCONQUEST1] 20131115 09:44:13 9999,0400      6 LO ConquestConsoleComma   "silent" [NHCONQUEST1] 20131115 09:45:13 Connected by address: 0100007f[NHCONQUEST1] 20131115 09:45:13 Testing transfer: '1.2.840.10008.1.2' against list #0 = '1.2.840.10008.1.2'[NHCONQUEST1] 20131115 09:45:13 0000,0002     18 UI AffectedSOPClassUID    "1.2.840.10008.1.1" [NHCONQUEST1] 20131115 09:45:13 0000,0100      2 US CommandField           48 [NHCONQUEST1] 20131115 09:45:13 0000,0110      2 US MessageID              7 [NHCONQUEST1] 20131115 09:45:13 0000,0800      2 US DataSetType            257 [NHCONQUEST1] 20131115 09:45:13 0002,0010     17 UI TransferSyntaxUID      "1.2.840.10008.1.2" [NHCONQUEST1] 20131115 09:45:13 9999,0400      6 LO ConquestConsoleComma   "silent" [NHCONQUEST1] 20131115 09:45:42 Server Command   := 0000[NHCONQUEST1] 20131115 09:45:42 Message ID       := 0000[NHCONQUEST1] 20131115 09:45:42 0002,0010     19 UI TransferSyntaxUID      "1.2.840.10008.1.2.1" [NHCONQUEST1] 20131115 09:45:42 ***Client Error: command ffff failed **[NHCONQUEST1] 20131115 09:45:42 ***Connection Terminated[NHCONQUEST1] 20131115 09:45:42 0002,0010     19 UI TransferSyntaxUID      "1.2.840.10008.1.2.1" [NHCONQUEST1] 20131115 09:45:57 Connected by address: 8303010a[NHCONQUEST1] 20131115 09:46:06 Testing transfer: '1.2.840.10008.1.2.1' against list #0 = '1.2.840.10008.1.2'[NHCONQUEST1] 20131115 09:46:06 Testing transfer: '1.2.840.10008.1.2.1' against list #1 = '1.2.840.10008.1.2.1'[NHCONQUEST1] 20131115 09:46:06 Testing transfer: '1.2.840.10008.1.2.1' against list #0 = '1.2.840.10008.1.2'[NHCONQUEST1] 20131115 09:46:06 Testing transfer: '1.2.840.10008.1.2.1' against list #1 = '1.2.840.10008.1.2.1'[NHCONQUEST1] 20131115 09:46:06 Testing transfer: '1.2.840.10008.1.2.1' against list #0 = '1.2.840.10008.1.2'[NHCONQUEST1] 20131115 09:46:06 Testing transfer: '1.2.840.10008.1.2.1' against list #1 = '1.2.840.10008.1.2.1'[NHCONQUEST1] 20131115 09:46:06 Testing transfer: '1.2.840.10008.1.2.4.50' against list #0 = '1.2.840.10008.1.2'[NHCONQUEST1] 20131115 09:46:06 Testing transfer: '1.2.840.10008.1.2.4.50' against list #1 = '1.2.840.10008.1.2.1'[NHCONQUEST1] 20131115 09:46:06 Testing transfer: '1.2.840.10008.1.2.4.50' against list #2 = '1.2.840.10008.1.2.4.50'[NHCONQUEST1] 20131115 09:46:06 Testing transfer: '1.2.840.10008.1.2.4.50' against list #0 = '1.2.840.10008.1.2'[NHCONQUEST1] 20131115 09:46:06 Testing transfer: '1.2.840.10008.1.2.4.50' against list #1 = '1.2.840.10008.1.2.1'[NHCONQUEST1] 20131115 09:46:06 Testing transfer: '1.2.840.10008.1.2.4.50' against list #2 = '1.2.840.10008.1.2.4.50'[NHCONQUEST1] 20131115 09:46:06 Testing transfer: '1.2.840.10008.1.2.1' against list #0 = '1.2.840.10008.1.2'[NHCONQUEST1] 20131115 09:46:06 Testing transfer: '1.2.840.10008.1.2.1' against list #1 = '1.2.840.10008.1.2.1'[NHCONQUEST1] 20131115 09:46:06


  • Update 1.4.17c released

    all my sites have had the problem now multiple times.
    The only machines that are having the problem are Philips IU-22 machines
    I enabled debug logging on all conquest instances in the hope this will capture what exactly is going on.
    I'll post the logs once it happens again

  • Private 3D Presentation State SOP

    After a year of testing with a new (secret) Philips ultrasound machine, we are finally allowed to talk about it.
    When this was added to the network and we tried to verify the DICOM capabilities against our conquest server, everything passed except for the Private 3D Presentation State SOP
    Everything was working, it is just showing ugly warning message
    [Blocked Image: http://i42.tinypic.com/erhgsh.jpg]


    Not really something that needs to be fixed or addressed, but just thought you might be interested in it

  • Update 1.4.17c released

    I just upgraded all our servers to 1.4.17c and am having some issues with Philips IU-22 machines
    Today in different sites we had these machines stop sending images until we restarted them.
    When looking through the logs I found the following:
    20131114 07:53:25
    ***Client Error: command ffff failed **
    20131114 07:53:25 ***Connection Terminated


    This is showing up already multiple times today in 2 of my locations.
    Is this a known bug or does anyone have suggestions on what might be going on?

  • gsdf calibrated

    We are ready to get a experimental Philips machine installed in our network.
    One of the questions the technicians are having before installing it is: is our conquest server gsdf calibrated?
    I did a search of the manual and forums, but wasn't able to find anything about this.


    Can anyone help out with this?


    Thanks

  • upgrade procedures

    I was going over our existing conquest servers and am planning on upgrading them from 1.4.16 to 1.4.17beta2
    I upgraded one of the servers earlier this year, and I just copied all the files to the same directory as my current installation.


    Is that the right way to go?
    Because I think there are a bunch of files there now that aren't doing anything and are redundant.
    Is there an upgrade procedure available for major version updates?


    Thanks,


    David

  • Increased filesizes

    Dicom config can be found at the bottom.
    Going back to 1.4.16j is not an option. We had severe crashing issues with that version. Sometimes up to 5 times a day in each of our locations.
    This was fixed when upgrading to 1.4.16k


    I have no real attachment to the NKI format. This is just the format the systems were using when we took over the IT infrastructure.
    I started reading more about this in the last couple days and decided that a change to DCM files with jpg lossless compression will do as good a job if not better of saving space, with the added benefit of being compatible with more devices.
    I know about the speed difference, which shouldn't be an issue once the initial conversion is completed.


    When I was moving the 9TB of nki images to the new server, it was going to finish in 53 hours.
    It seems that moving the same amount to DCM and jpg compression will be over 200 hours.


    After reading this thread and testing myself I had a couple more questions:
    - If there is a bug in the NKI format since the latest version, does that mean all images created since then are larger than supposed to and will need to be recompressed later on to gain space?
    - Are there any other considerations in choosing between V2/NKI and DCM/jpg except for compression speed and compatibility?


    If one or the other is clearly better I have the ability to switch some servers and storage around to convert all of them to the same format. (for now, that none of the locations has more than 10TB yet)


  • Increased filesizes

    We are moving our current archive pacs server to new hardware.
    When transferring the files between our 2 servers I noticed they are increasing in size, approx 200%.
    Both servers are set up with exactly the same configuration.


    JPEG2000 support
    NKI compressed
    Saved as V2


    IncomingCompression = n4


    When speccing out the new server, we calculated in future growth, but no increase in moving the files.


    Is there anyone that can shed any light on why this might be happening and if this is preventable?


    Thanks

  • Advise on set-up

    Hmm, just thought of something that might invalidate this whole train of thought.
    When moving images into the folder on the archiveserver, I'll need to ask conquest on the archiveserver to recheck for new images every night.
    Which will take forever, so might not be the best option


    Seems I might just need to keep using my script that runs nightly to manually copy studies from our local conquest to the archive server
    (the script queries the database for studies added on todays date and then runs a command line script with c:\conquest\dgate64.exe --moveseries:....)
    And before I enable to cleanup script to make absolutely sure I compare both servers to see that everything local is on the archive server


    Just thought I could simplify things, but might not be as easy as I thought unless there is an option to do the archival in a way the archive server is aware of the images added
    Thanks for the help anyway!

  • Advise on set-up

    Thanks for the quick reply


    Will conquest actively check for duplicates?
    Since with my proposed setup there would be loads of duplicates
    MAGDevice0 = E:\SSImages\
    MAGDevice1 = \\archiveserver\images\


    All images in MAGDevice0 will also be in MAGDevice1
    I thought this wouldn't be a problem since Conquest would never need to save anything in MAG1 as long as there is enough space on MAG0


    What I wanted to try and do with the setup is set up mirrordevice to make sure everything from now on gets copied on our archiveserver automatically
    and before the nightly cleanup move old images to the archive server as well instead of just deleting them (since I don't know if all our old ones are there)

  • Advise on set-up

    my intention is not to use mag1 as an overflow device
    so all new images would be written to mag0 and mirrored to the archiveserver
    and I was just looking for a way to copy all images before we do a purge to that same archiveserver, to make absolutely sure nothing is missed and deleted
    can I do NightlyMoveTarget = \\archiveserver\images\ if it's not recommended to define a mag1 and not use it for the intended purpose as overflow device?