Posts by joelspangler

    This is technically possible, however I'm not seeing any way to do it via the GUI. You can change PatientID (MRN) in the gui, but I couldn't find a way to change a name or Accession number (accession being a very important ID for most US PACS installations), via the GUI. You could set up a separate instance of conquest specifically for changing needed DICOM tags via the dicom.ini - each time you need to change something you'd need to modify the dicom.ini first. Something like this as an importconverter should work (untested)


    ImportConverter0 = Set 0010,0010 to "InsertPatientNameHere"; Set 0010,0020 to "InsertPatientIDHere"; Set 0008,0050 to "InsertAccNumHere"; forward to PACS


    The "forward to PACS" in my instance would cause problems - my PACS wouldn't take kindly to the same StudyInstanceUID being associated with two different patients - the original (BAD) data would need to be removed from PACS first. If I were doing this, I'd need to remove the "forward to PACS" part and then manually send the study from conquest to PACS.


    That said there are better tools for this - we have two specialty DICOM editor tools that we use for situations like this. Both of them are commercial tools, and aren't free (I'm unsure if I'm allowed to mention specific names of the commercial tools on this forum). Both commercial tools have image editing capabilities so if the patient's information is "burned into" the image (pixel) data, that can be fixed too. Conquest can also cover pixel data (see my forum thread for the blockpixel.lua script), but again it's done programmatically and isn't super easy to use.

    We've started using Conquest as a tool for anonymization and storage of studies for research archives (using the provided anonymize_script.lua, as well as the blockpixel.lua script I previously documented). So far, the DICOM has been kept in house, but an upcoming project will require data to be sent of-site. Our research group has requested some additional tweaks to further anonymize the data - both of which are above my current programming skill level. Any help/direction you can give me would be appreciated.


    #1 - Modify dates. We discussed using a random + or - 1 to 14 days on every study coming in. At first the thought was to randomly generate a different number for each study, but then the concern of prior studies not being in the correct order (such as daily chest x-rays) might be a problem. What they asked is that we just modify the dates in the DICOM by a static number. Is there a function in Conquest (or in LUA) that could add or subtract days to a date?


    #2 - Remove all Private DICOM tags. We've found that randomly some modalities add patient demographics into private DICOM tags. I've accounted for some specific tags that we've found by adding them to the anonymize_script.lua, but the proposition has been made to just remove every private dicom tag to eliminate this possibility. From my understanding, tags greater than 0008,0000 where 000X,0000 is odd are considered private tags. Is there an easy way to programmatically identify and remove these?

    yep - running my lua script as my only importconverter and ImportExportDragAndDrop is enabled. I'm using a watchfolder to drop the file into.


    Using your script results in a new file being saved under c:\dicomserver (this new file gets decompressed creating a much larger file size). Unfortunately the file stored to the mag device is the original DICOM file, and not the expanded/fixed DICOM file.

    on version - 1.4.17d


    I am trying to duplicate from within a lua script. I've tried:
    os.execute ('C:\\DicomWorking\\UC.bat '..Filename)
    print(script('forward to PACS'))
    In the above example, UC.bat runs gdcmconv on the file, but the file that conquest forwards to PACS and stores is still the original/bad DICOM.


    I also tried modifying UC.bat to run gdcmconv and send via storescu (and removed the forward to pacs in the lua) - this results in Good images in PACS, but conquest is still storing the orginal/bad DICOM in it's database. Is there something other than "Filename" that I should be referencing?

    I have a lot of data resulting from an acquired hospital's migration that must not be fully DICOM compliant. Our PACS displays them as sort of a ghost outline with a grey background. Once uncompressed, these images display fine in my PACS, but conquest doesn't properly uncompress the file (using builtinJPEG or without). Sante DICOM editor can/does uncompress them successfully, as well as command line tool gdcmconv.exe (part of the Grassroots dicom package - documentation here - http://gdcm.sourceforge.net/html/gdcmconv.html)


    Neither of those tools are particularly user friendly, and I hope to be able to automate using one of my Conquest instances. The manual hints about being able to use an external program to modify files (as part of an exportconverter), but I couldn't find any examples of how to do this. Can this also be done with an importconverter? (I'd need to run the executable, as well as some command line options - including the path to where the file is located)


    Also - if you would want to take a look at some of the files to see WHY it failed in the first place, please let me know.


    Thanks in advance!

    A lot of the work is discovering what pixels need to be covered up - that work won't be lost. If the functions that I built are improved upon (such as your "neat trick" mentioned above") I wouldn't be upset about that at all. I don't know if building a function directly into dgate.exe to anonymise a "block" or range of pixels would be appropriate/faster than doing it in LUA.

    setpixel(row, col, frame, 0, 0, 0) works on color images, and does not seem to adversely affect b/w images... although I think it's actually setpixel (col, row, frame, 0, 0, 0). I'll play with a different model US perhaps one that uses color cine loops to see if I can find anything it doesn't work on. I'll post updated scripts as I find time to research where PHI is "burned in" for different models of machines.


    As far as speed, it seems conquest is keeping up fine, even if I queue multiple exams back to back from my PACS. Since I rarely blank a whole row, I don't know that the getrow/setrow would be very useful at this point.

    I can now block areas in CINE loop objects, and am tweaking the script as needed to block out as much PHI as possible. My major limitation to completely anonymizing data at this point is color frame ultrasound images. As far as I can tell, dgate is trying to do something with the color images, but it fails to actually change the pixels.


    Here's my current script which now includes a blockcine funtion. I've been focusing on GE Logic E9 ultrasounds. These are a bit annoying because PHI is "burned in" at different locations for 3 different kinds of images (Cover pages, Regular single frame images, and CINE loop images). Coming up with ways to identify these different types of images was fairly difficult, but this current revision has been successful in every images set from an E9 that I've thrown at it.


    What is the best way to get the file to "un" before processing? Would I need to set storage on my archive to "un", and run my LUA as an exportconverer (rather than an inportconverter), or is there another way to decompress without requiring my archive to be set to "un"

    I am on 1.4.17d, and haven't found a multi-frame image that hasn't caused a crash yet. Could it be the compression of the image causing the problems? Should I try to make the program change the file to "un" first before trying to modify it. My current code also is setting frame 0 - setpixel(c, r, 0, 0) which works fine for single frame black and white files... do I need to start with frame 1 on multi-frame files?


    Also, I'm having trouble identifying some series with "burned in" information. There is useful information in private tags, but I'm unable to figure out how to address private tags within LUA. I tired to do the following as a test. print ('tagtest', Data.00731003) --- That resulted in an error: D:\dicomserver-SQL\lua\BlockPixel1.lua:13: ')' expected near '.00731003'. Is there a way to address a specific "unnamed" or "private" tag?


    I tried to figure out the setrow command - the syntax appears to be SetRow(y, frame, table). I tried setrow(1, 1, 0) - which causes dgate to crash. For "table" - would I have to create a table with the correct number of pixels to run this command?


    Lastly, I figured out how to create a function - the code below does almost exactly what the one I posted yesterday does, but this one would be a bit easier for others to add to if/when it goes into more of a production mode.

    I am starting to write up a lua script to block out pixel data (such as patient names on ultrasounds and CT dosage reports) as part of a research project that requires anonymized data. I have successfully gotten single frame images blocked out, but when multi-frame images are sent to Conquest, I get an error message "dgate64.exe has stopped working" message (details below). Conquest logs do not contain any information as to why it crashed.


    Here's the lua script that I am running - this is in the VERY early stages. I will eventually research how to create a function with LUA so it's a little less repetitive. I will also eventually need to figure out how to tell the script to change multiple frames on multi-frame files (is there a way to get a count of frames?)... First things first is to figure out why it is crashing when trying to handle multi-frame images. The section of code it's choking on would be the code under the "-- US GE Logiq E9 normal images" comment


    Code
    -- Script to anonymize pixels when certain conditions are met--uncomment below print statements (and last line of this document)for debugging--print('------ Anon Pixel script running --------')--print ('Manuf', Data.Manufacturer)--print ('SeriesNum', Data.SeriesNumber)--print ('Modality', Data.Modality)--print ('SeriesDesc', Data.SeriesDescription)--print ('ManufacturerModelNam', Data.ManufacturerModelName)--print ('imagenumber', Data.ImageNumber)--print ('imagedesc', Data.ImageDescription)--print ('InstanceNumber', Data.InstanceNumber)-- Toshiba CT dose pageif Data.Manufacturer == "TOSHIBA" and Data.SeriesNumber == "1000" and Data.Modality == "CT" then print('------ condition for Toshiba dose page met------') for r=0, 300 do for c=0, 511 do setpixel(c, r, 0, 0) end endend-- CT Series named "screen save"if Data.SeriesDescription == "Screen save" then print('------ condition for screen save page met------') for r=0, 63 do for c=300, 511 do setpixel(c, r, 0, 0) end endend-- US GE Logiq E9 Cover Pageif Data.ManufacturerModelName == "LOGIQE9" and Data.InstanceNumber == "0" then print('------ condition for LogicE9 cover page met------') for r=16, 45 do for c=175, 350 do setpixel(c, r, 0, 0) end for c=510, 685 do setpixel(c, r, 0, 0) end for c=830, 950 do setpixel(c, r, 0, 0) end end for r=65, 90 do for c=175, 350 do setpixel(c, r, 0, 0) end for c=510, 685 do setpixel(c, r, 0, 0) end for c=830, 950 do setpixel(c, r, 0, 0) end end for r=110, 140 do for c=510, 685 do setpixel(c, r, 0, 0) end endend-- US GE Logiq E9 normal imagesif Data.ManufacturerModelName == "LOGIQE9" and Data.InstanceNumber ~= "0" then print('------ condition for GE LogiqE9 normal images met------') for r=0, 65 do for c=338, 670 do setpixel(c, r, 0, 0) end endend--print('------ Anon Pixel script stopping --------')


    And below is the details on the dgate64.exe crash as reported by windows.

    never mind - working! I started putting files back to the original versions and trying again. I am able to get images if I remove the "header = Content-type: text/xml\" line that I previously added to the dicom.ini [weasisseriesxml] and [weasisstudyxml] sections.


    So it will and does work in IIS. I believe the following are all necessary to make it work:
    - make cgi-bin directory an app directory (right click and choose convert to application)
    - Add a handler mapping/Script map inside the cgi folder. Request path = *.exe, Executable = C:\inetpub\wwwroot\cgi-bin\dgate.exe
    - make weasis directory an app directory (right click and choose convert to application)
    - Add MIME type application/x-java-jnlp-file for .jnlp files (can be done within weasis folder, or at the default site level)
    - Add MIME type text/plain for .properties files (I did this at the default site level)
    - change cgi-bin\LaunchWeasisStudy.cq and launchWeasis.cq files to point to a specified port# (Only required if you are not using the html port - port 80)


    I believe those are the only changes that I made that were actually required. I did a lot of "playing" within the directory and may have made another required change without realizing it. If I ever get a chance to load a "fresh" copy again, I'll try to verify that nothing else was needed.

    I finally got weasis to launch - but I'm not seeing any images. My launching issue was that the config.properties and ext-config.properties were not being serverd up correctly. I created a MIME type for .properties of text/plain, which finally make weasis open. Any thoughts on why it isn't launching images? I know I am not supposed to hit the xml link directly, but shouldn't I at least see something in the browser (other than an error) when pulling up the link?


    http://10.230.30.70:8080/cgi-b…399385632.349.23&dum=.xml

    we both submitted new info around the same time. The error above was before I made a change. In the dicom.ini file I only had


    [weasisstudyxml]
    source = viewers\weasisstudyxml.lua


    I have added in header = Content-type: text/xml\ and now get a different error.

    Code
    The XML page cannot be displayed
    Cannot view XML input using style sheet. Please correct the error and then click the Refresh button, or try again later.
    --------------------------------------------------------------------------------
    Invalid at the top level of the document. Error processing resource 'http://tstvnadbw8k1v:8080/cgi-bin/dgate.exe?port=107&a...
    Content-Type: application/xml

    I found I get a different error in IE when trying to go to http://tstvnadbw8k1v:8080/cgi-…399385632.349.23&dum=.xml In IE, I'm seeing.

    Code
    The XML page cannot be displayed
    Cannot view XML input using style sheet. Please correct the error and then click the Refresh button, or try again later.
    --------------------------------------------------------------------------------
    XML document must have a top level element. Error processing resource 'http://tstvnadbw8k1v:8080/cgi-bin/dgate.exe?port=107...

    It is set up, but I don't think the web server is processing it properly, and dgate can't run it. I tried giving .lua files a mime type of text/plain, as well as application/xml within IIS, and neither caused any change. I also tried creating a handler mapping for *.lua to C:\inetpub\wwwroot\cgi-bin\dgate.exe, but that also doesn't seem to work.


    quick question - when you go to /cgi-bin/viewers/weasisseriesxml.lua, what is served up? By default (no config changes) I got "page not found". When I switched it to plain text, I got plain text print out of the file. With application/xml I got an error (below) and with a handler mapping I get the "Default script: reached because [DefaultPage] source=*.lua is set in dicom.ini " which is what I also see when going to /cgi-bin/dgate.exe without any options.


    Code
    XML Parsing Error: syntax error
    Location: http://tstvnadbw8k1v:8080/cgi-bin/weasisseriesxml.lua
    Line Number 1, Column 1:-- updated to pass compress mode, mvh 20140126

    I thought I had it - but alas still having problems. The XML pointer in the above example did not include the :8080 - I thought that was my issue, but updating the .cq files for the correct address didn't make any changes to behavior.


    I tried going to http://tstvnadbw8k1v:8080/cgi-…399385632.349.23&dum=.xml and am getting error:


    Code
    XML Parsing Error: no element found
    Location: http://tstvnadbw8k1v:8080/cgi-bin/dgate.exe?port=107&address=10.230.30.70&mode=weasisstudyxml&study=1137323678.1864233347:1.2.826.0.1.3680043.2.135.735333.28061483.7.1399385632.349.23&dum=.xml
    Line Number 1, Column 1:

    I also re-read your original question - just so you understand how this works - you must have an instance of conquest up and running - the dgate.exe that the web server runs serves up web pages, but communicates with the other instance of conquest to view/delete studies. Keep that in mind as you set up the dicom.ini file that is in the cgi-bin folder.