Posts by marcelvanherk

  • Simple WEB-DICOM-Viewer for Conquest

    Hi,


    here is a first conquest web interface that includes a k-pacs viewer (preliminary, windows only).


    ftp://ftp-rt.nki.nl/outbox/Mar…/conquest_for_cgi-bin.zip


    To install, unzip the contents of the file into your cgi-bin directory (e.g., C:\wamp\Apache2\cgi-bin).
    Then (only) edit the dicom.ini stored there according to your local installation.
    To finish copy the new dgate.exe also into your previously installed conquestdicomserver directory (no further changes needed).


    It was tested with wamp1.6.6, conquest dicom server 1.4.12c, and IE6sp1.


    The server runs from http://127.0.0.1/cgi-bin/dgate.exe?mode=top.
    Query for patients and studies and then click view from the series browser to activate the new viewer, an activeX control.


    A known isssue is that many browsers download the html code produced by dgate.exe instead of displaying it.
    Also you may need to lower the security setting of your browser to get the activex control installed.


    Have fun! Any comments are appreciated.


    Marcel

  • problem troubleshooting a **Error saving to SQL message.

    Hi,


    this message (hologic) normally appear when the same series is re-inserted but now belonging to another study - this is forbidden. The later one (fairlight) that the same image is re-inserted for a different series - again forbidden. Where do you set the accessionnumber? Default it is just stored but further ignored by conquest - indicating maybe a bug on the sending site. Also the double point in the hologic UID is strange '70918..1'.


    Can you check to see differences between the log and the contents of the server (db, headerdump) for these data (focus on patientid, studyuid and seriesuid)?


    Marcel

  • Why not to change patientID of a dicom image

    This is an attempted explanation for a problem that can occur in DICOM when you change the patient ID if an image (explanation work in progress):


    A dicom image is identified by four identifiers:


    patientID e.g., 9904321
    studyUID e.g. 1.2.826.0.1.3680043.2.135.732714.83501593.90102.7766
    seriesUID e.g. 1.2.826.0.1.3680043.2.135.732714.83501593.90102.7767
    imageUID e.g. 1.2.826.0.1.3680043.2.135.732714.83501593.90102.7768


    UID's have no meaning except that are intended to be globally unique, that's why they are so long.


    When an image is stored in conquest or other dicom archives, four databases are updated: DICOMpatients, DICOMstudies, DICOMseries, and DICOMimages. The UID's are keys to this table, i.e., each record has a different UID. The study database refers to the patientID, the series database refers to the studyUID, etc. When multiple images of the same series are loaded only the DICOMimages database grows, the rest stays the same.


    When you query the database or load an image it is a simple matter to go through the databases to access all image, study, series and patient related information.


    What happens when somebody edits the patient ID and stores the same image again in a DICOM server?


    patientID e.g., 9901234
    studyUID e.g. 1.2.826.0.1.3680043.2.135.732714.83501593.90102.7766
    seriesUID e.g. 1.2.826.0.1.3680043.2.135.732714.83501593.90102.7767
    imageUID e.g. 1.2.826.0.1.3680043.2.135.732714.83501593.90102.7768


    The server should see that the image is already stored - no change. It should see that the series is already stored - no change, and that the study is already stored - no change. But then, it sees that the patient ID differs. It could change the patientID in the study database and this image is stored correctly. But all other images stored before would become invalid: the database does not correspond with the other images of the series. Or it could keep the old patientID and then the modified image would become invalid: the database does not correspond with the image.


    So actually, the server has no choice but to reject the modified image: because the same image, series and study would belong to more than one patient. This happens on most full sql servers, as the uniqueness of the UID index to the study databases would be broken. However, on older versions it does not happen on dbaseIII: this is a bug. Actually in dbaseIII the study would be entered twice, each with a different patientID. But a series or image query will return only a single study, so the images of the other patient are 'lost'. This bug is fixed in 1.4.14beta.


    If you do need to change the patient ID, use the conquets dicom server to do it. In the conquest dicom server, all UID's are changed when the patientID is changed: so that the modified image does not conflict with the original image when loaded into the same archive. The relation between old UID and new UID is kept in table UIDMods, so that multiple images can be modified wihout breaking their organization in series and studies. This mechanism is used for "change patient ID", anonymize, split and merge.


    Marcel

  • Working with NAS as storage path

    I'm also really lost. The same dgate.exe and the same settings are used as service or not. I tried to write at home from one win2000 machine to a share on another - no problem as service or not. Something fundamental must have changed to the way services behave with xpsp2 or: you said your share is a NAS, maybe it is a problem in the NAS software. You might try a share to a normal server.


    Marcel

  • Import DICOM images from filesystem

    Hi,


    I guess you can alt-drop with the original patientID: it will still generate new UIDs. The translation old-uid to new-uid is stored in a database table and will be reused for other images as well. Notice that changing a patient ID twice will not get the same image back! It will have new UIDs.


    Marcel

  • Oracle 10G conection

    The string should have read like this:


    SELECT StudyInsta,StudyDate,StudyTime,StudyID,StudyDescr,AccessionN,ReferPhysi,PatientsAg,PatientsWe,StudyModal,StationNam,Institutio,PatientNam,PatientBir,PatientSex,PatientID FROM DICOMStudies WHERE StudyInsta = '1.3.6.1.4.1.2452.1.1.1000.20000529164628.1' AND PatientID = '111111-1111'


    And has done so for countless images. Is there something strange with your image (missing studyuid). Other images saved correctly?


    Marcel

  • Import DICOM images from filesystem

    You did try drag an drop: it will load a whole directory tree in one go.


    Also try keeping alt pressed while dropping files for a single patient: you can modify patient ID. It will then generate a new set of UIDs. We do this to avoid conficts between the original and modified image when to are stored in the same archive.


    Marcel

  • Manual

    Hi,


    your forwarding rule is not supported. Only recieved images are forwarded, not priors. Maybe something for the future.


    Move the v2 files out of the directory, regen ;->>> and drag and drop the .v2 files into the server. They get converted and renamed as they are stores. Or copy the .v2 files, delete relevant studies and drag and drop them in again.


    Marcel

  • Linux installation of ConQuest

    Hi, as short as possible: but conquest on linux is preliminary (no GUI and install packages).


    (ps)ftp zips to linux system


    unzip conquestlinux1412c.zip
    cd conquest
    chmod 777 maklinux
    maklinux


    (optional for JPEG support)
    cd ..
    unzip jpegsuplinux1412.ZIP -d conquest
    chmod 777 conquest/dcmdjpeg
    chmod 777 conquest/dcmcjpeg
    cd conquest
    (end optional)


    dgate -v -r
    dgate -v


    Now up and running. You need to edit acrnema.map to make other servers known to conquest.