Posts by marcelvanherk

  • 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.

  • SQL Server Express

    The server console is 39 MB and requires service XP pack 2. An easier alternative: install MSDERalA (sql 2000 desktop version) - if you can still find it - with:


    setup SAPWD="conquest" SECURITYMODE=SQL


    start MSSQLSERVER service


    osql /Usa /Pconquest
    1> create database conquest
    2> go


    1> exec sp_addlogin 'conquest','conquest','conquest'
    2> use conquest
    3> exec sp_changedbowner 'conquest'
    4> go
    1>^C


    start dicomserver installation
    Database type: SQL Server Database
    Save config
    Verify tcp/ip
    make ODBC: server = (local), database = conquest
    start the conquest dicom server
    go to installation page
    verify database install
    reinit database


    NOW YOU ARE UP AND RUNNING


    Marcel

  • Simple WEB-DICOM-Viewer for Conquest

    Hi,


    I guess you need to create an ODBC access to mysql with myodbc, that will be the only thing that microsoft supports. As webgate bypasses the server you can (and must in this case) use different access methods for the server and webgate.


    Marcel

  • Working with NAS as storage path

    Michael


    Your service must still have insufficient rights to write to the NAS. The initial test is to avoid the situation you just saw: failure to write to MAG0.


    On my win2000 system I see (I just tested changing the logon):


    start - controlpanel - admin - services:
    CONQUESTSRV1 (empty) Started Automatic .\marcel


    The latter is the logon, which I changed from LocalSystem to in my case ./marcel, which could be YOURDOMAIN/marcel in a domain environment. The logon sets the rights to the disks and shares. Sometimes there is both a local user and a domain user - these probably have different rights - that could be your problem.


    Good luck!


    Marcel