Posts by syswiz

  • Patient ID change

    Marcel, is there an easier way to change a Patient ID for all of a patients studies. Right now, I am going to the database browser, right mouse clicking on a study, and selecting "change patient ID for this study". If the particular patient has several studies across different modalities, it takes a long time to do each one. Is there a dgate command line I could do, or a way to select multiple studies at a time to change?

  • Delay 5 minutes before forwarding

    Is it the "ForwardCollectDelay" that works in conjunction with "forward study to"? For example, if I want to have RF study defer for 5 minutes before being forwarded, is this the correct dicom.ini?


    Code
    # Forwarding Rules

    ForwardAssociationLevel = STUDY

    ForwardAssociationCloseDelay = 5

    ForwardAssociationRefreshDelay = 3600

    ForwardCollectDelay = 300

    ExportConverters = 1

    ExportConverter0 = forward study to REMOTEREAD

    ExportModality0 = RF

  • Forwarding to eFilm 3.0

    Doing a search, I've read where eFilm 3.0 has some issues with certain DICOM header values being empty, but not where eFilm 3.0 has a problem with forwarded studies ONLY. eFilm 2.0 does NOT have this problem, only 3.0.


    I am sure it is an export setting I munged up in dicom.ini. Can someone take a look and point me in the right direction?


    Here is the eFilm log entry:

    Code
    (1720) 08-20 12:45:17.73 MC3  E: Error on Read_Transport call(1720) 08-20 12:45:17.73 MC3  E: Error on Read_PDU_Head call: Transport has shut down(1720) 08-20 12:45:17.73 MC3  E: Transport unexpectedly closed(1720) 08-20 12:45:17.73 MC3  I: DUL_read_pdvs error: UL Provider aborted the association(1720) 08-20 12:45:17.73 MC3  E: (0000,0000): Error during MC_Stream_To_Message:(1720) 08-20 12:45:17.73 MC3  E: |   Callback cannot comply(1720) 08-20 12:45:17.73 MC3  E: Network connection unexpectedly shutdown(1720) 08-20 12:45:17.73 CStoreRoot::SCPStore: An association(ID= 10080) is shut down or aborted!


    Here is the Forwarding section of dicom.ini:


    READSTATION - eFilm 3.0.1
    PACSSERVER - Conquest 1.4.13
    OEC_9800 - C-Arm


    If I send from OEC-9800 to PACSSERVER, it forwards the study to READSTATION. The study appears to make it, but the eFilm queue shows FAILED, with a NETWORK UNEXPECTEDLY SHUTDOWN comment.
    If I send the same study from the conquest UI, it works JUST FINE. I have done other tests as well: eFilm -> Conquest forward -> eFilm and it also gives that message.


    In a nutshell, ANY study FORWARDED from conquest gives that failed message. Can anyone shed some light??? Thanks a bazillion. -Scott

  • Violation of PRIMARY KEY constraint troubleshooting

    Marcel,
    What is the best way to determine what is violating the PRIMARY KEY constraint? I am banging my head on this. We don't have a worklist running yet, so I am at the mercy of the technologist. Here is part of the verbose log of the problem patient. Where can I look to determine the problem? We're running SQL2005 as the database. I've checked the usual suspects (name, patid, birthdate, sex), but all seem consistent with previous studies of the same patient already in Conquest. Please help. -Scott


    Code
    20080611 12:55:49 ***Failed SQLExecDirect : INSERT INTO DICOMImages (SOPInstanc, SOPClassUI, ImageNumbe, ImageDate, ImageTime, EchoNumber, AcqDate, AcqTime, ReceivingC, AcqNumber, SliceLocat, SamplesPer, PhotoMetri, Rows, Colums, BitsStored, ImageType, ImagePat, SeriesInst, AccessTime, ObjectFile, DeviceName) VALUES ('1.2.392.200036.9123.100.12.11.21087.20080530192735.6.44', '1.2.840.10008.5.1.4.1.1.4', '44', '20080530', '192352.560', '2\11', '20080530', '192352.560', 'MA Flex Body(L)', '1', '-51.2', '1', 'MONOCHROME2', '256', '256', '16', 'ORIGINAL\PRIMARY\OTHER', '9511', '1.2.392.200036.9123.100.12.11.21087.20080530192735.6', 1213214144, '1.2.392.200036.9123.100.12.11.21087.2008053020185150\1.2.392.200036.9123.100.12.11.21087.20080530192735.6\1.2.392.200036.9123.100.12.11.21087.20080530192735.6.44.dcm', 'MAG0')

    20080611 12:55:49 ***Error: 2627: 23000: [Microsoft][ODBC SQL Server Driver][SQL Server]Violation of PRIMARY KEY constraint 'PK__DICOMImages__24927208'. Cannot insert duplicate key in object 'dbo.DICOMImages'.

    20080611 12:55:49 ***Unable to DB.Add()

    20080611 12:55:49 ***SQL: INSERT INTO DICOMImages (SOPInstanc, SOPClassUI, ImageNumbe, ImageDate, ImageTime, EchoNumber, AcqDate, AcqTime, ReceivingC, AcqNumber, SliceLocat, SamplesPer, PhotoMetri, Rows, Colums, BitsStored, ImageType, ImagePat, SeriesInst, AccessTime, ObjectFile, DeviceName) VALUES ('1.2.392.200036.9123.100.12.11.21087.20080530192735.6.44', '1.2.840.10008.5.1.4.1.1.4', '44', '20080530', '192352.560', '2\11', '20080530', '192352.560', 'MA Flex Body(L)', '1', '-51.2', '1', 'MONOCHROME2', '256', '256', '16', 'ORIGINAL\PRIMARY\OTHER', '9511', '1.2.392.200036.9123.100.12.11.21087.20080530192735.6', 1213214144, '1.2.392.200036.9123.100.12.11.21087.2008053020185150\1.2.392.200036.9123.100.12.11.21087.20080530192735.6\1.2.392.200036.9123.100.12.11.21087.20080530192735.6.44.dcm', 'MAG0')

    20080611 12:55:49 ***Error: 2627: 23000: [Microsoft][ODBC SQL Server Driver][SQL Server]Violation of PRIMARY KEY constraint 'PK__DICOMImages__24927208'. Cannot insert duplicate key in object 'dbo.DICOMImages'.

    20080611 12:55:49 ***Error saving to SQL: 1.2.392.200036.9123.100.12.11.21087.2008053020185150\1.2.392.200036.9123.100.12.11.21087.20080530192735.6\1.2.392.200036.9123.100.12.11.21087.20080530192735.6.44.dcm

  • Violation of PRIMARY KEY constraint troubleshooting

    Marcel,
    I got a call from the technologist saying that a study had an error going to the Conquest server. I looked in the logs and found the following:


    Code
    [size=10]20080530 11:38:11 ***[AddImageFile] Error entering object into server: D:\1.2.392.200036.9123.100.12.11.21087.200805305091415\1.2.392.200036.9123.100.12.11.21087.20080530093833.3\1.2.392.200036.9123.100.12.11.21087.20080530093833.3.7.dcm

    20080530 11:38:11 ***Failed SQLExecDirect : INSERT INTO DICOMImages (SOPInstanc, SOPClassUI, ImageNumbe, ImageDate, ImageTime, EchoNumber, AcqDate, AcqTime, ReceivingC, AcqNumber, SliceLocat, SamplesPer, PhotoMetri, Rows, Colums, BitsStored, ImageType, ImagePat, SeriesInst, AccessTime, ObjectFile, DeviceName) VALUES ('1.2.392.200036.9123.100.12.11.21087.20080530093833.3.8', '1.2.840.10008.5.1.4.1.1.4', '8', '20080530', '093544.270', '1\5', '20080530', '093544.270', 'MA Head', '1', '15.5', '1', 'MONOCHROME2', '256', '256', '16', 'ORIGINAL\PRIMARY\OTHER', '11452', '1.2.392.200036.9123.100.12.11.21087.20080530093833.3', 1212172672, '1.2.392.200036.9123.100.12.11.21087.200805305091415\1.2.392.200036.9123.100.12.11.21087.20080530093833.3\1.2.392.200036.9123.100.12.11.21087.20080530093833.3.8.dcm', 'MAG0')

    20080530 11:38:11 ***Error: 2627: 23000: [Microsoft][ODBC SQL Server Driver][SQL Server]Violation of PRIMARY KEY constraint 'PK__DICOMImages__24927208'. Cannot insert duplicate key in object 'dbo.DICOMImages'.

    20080530 11:38:11 ***Unable to DB.Add()

    20080530 11:38:11 ***SQL: INSERT INTO DICOMImages (SOPInstanc, SOPClassUI, ImageNumbe, ImageDate, ImageTime, EchoNumber, AcqDate, AcqTime, ReceivingC, AcqNumber, SliceLocat, SamplesPer, PhotoMetri, Rows, Colums, BitsStored, ImageType, ImagePat, SeriesInst, AccessTime, ObjectFile, DeviceName) VALUES ('1.2.392.200036.9123.100.12.11.21087.20080530093833.3.8', '1.2.840.10008.5.1.4.1.1.4', '8', '20080530', '093544.270', '1\5', '20080530', '093544.270', 'MA Head', '1', '15.5', '1', 'MONOCHROME2', '256', '256', '16', 'ORIGINAL\PRIMARY\OTHER', '11452', '1.2.392.200036.9123.100.12.11.21087.20080530093833.3', 1212172672, '1.2.392.200036.9123.100.12.11.21087.200805305091415\1.2.392.200036.9123.100.12.11.21087.20080530093833.3\1.2.392.200036.9123.100.12.11.21087.20080530093833.3.8.dcm', 'MAG0')

    20080530 11:38:11 ***Error: 2627: 23000: [Microsoft][ODBC SQL Server Driver][SQL Server]Violation of PRIMARY KEY constraint 'PK__DICOMImages__24927208'. Cannot insert duplicate key in object 'dbo.DICOMImages'.

    20080530 11:38:11 ***Error saving to SQL: 1.2.392.200036.9123.100.12.11.21087.200805305091415\1.2.392.200036.9123.100.12.11.21087.20080530093833.3\1.2.392.200036.9123.100.12.11.21087.20080530093833.3.8.dcm[/size]


    Here's what I have figured out so far, could you please tell me if I am on the right track? The patient already existed in the database with a Patient ID of 11542. The tech was sending the same patient with a Patient ID of 11452. Is that the Primary key violation? If so, then why does it say in the Conquest manual that "The PatientName, PatientBirthDate and PatientSex items are duplicated in the study table (database rev8 and up), to allow detection of patient ID mix-ups." It sounds like it should have accepted the fat fingered Patient ID, doesn't it - or is the Patient ID the holy grail, and must be consistent? Could you steer me in the right direction? Thanks! -Scott

  • new to Conquest, v2 vs dcm, one directory vs subs

    Check the dicom.ini file. Look for the FileNameSyntax = x line. We use eFilm and are used to using 9 for our value. I have included the section from the manual that discusses FileNameSyntax below:




    FileNameSyntax Determines name of stored files, default 3. May be changed at any time
    depending on the requirements of an application that wants to read the files directly. Only
    affects newly stored images. Modes higher than 3 accept IODs without image or series number
    and are therefore suited for DICOM-RT. Options 3 and 4 force use of the cleaned PatientID as
    patient directory name, making sure that only a single directory is made for each unique patient
    ID. Option 5 uses the patient name as directory name. Options 6 to 9 provide several frequently
    used DICOM directory structures. From version 1.3.11, time is printed unsigned and the
    counter portion of the filename is extended from 2 to 4 digits. Modes 4, 8 and 9 store images in
    (the slower to read) standard chapter-10 DICOM format. DICOM-Works users might like mode
    8 or 9 best. See also note below. Conquest addition.


    0 (original):
    filename = ID[8]_Name[8]\Series#_Image#_Time.v2
    1 (safer version of original):
    filename = ID[8]_Name[8]\Series#_Image#_TimeCounter.v2
    2 (include series UID in filename to ensure names sort by series):
    filename = ID[8]_Name[8]\Seriesuid_Series#_Image#_TimeCounter.v2
    3 (Uses patient ID as directory name and sets DICOM-RT required flags):
    filename = ID[16]\Seriesuid_Series#_Image#_TimeCounter.v2
    4 (same as 3, but data is stored in chapter 10 format):
    filename = ID[16]\Seriesuid_Series#_Image#_TimeCounter.dcm
    5 (sets DICOM-RT required flags, uses untruncated patient name as directory):
    filename = Name\Seriesuid_Series#_Image#_TimeCounter.v2
    6 (standard DICOM directory structure starting at patient root):
    filename = ID[32]\Studyuid\Seriesuid\Imageuid.v2
    7 (standard DICOM directory structure starting at study root):
    filename = Studyuid\Seriesuid\Imageuid.v2
    8 (standard patient root DICOM directory structure in chapter 10 format):
    filename = ID[32]\Studyuid\Seriesuid\Imageuid.dcm
    9 (standard study root DICOM directory structure in chapter 10 format):
    filename = Studyuid\Seriesuid\Imageuid.dcm
    10(all files in one directory)
    filename = Images\Imageuid.dcm
    11(patient name as directory, UIDS as subdirectories)
    filename = Name\StudyUID\SeriesUID\Imageuid.dcm
    12(patient name_id as directory, modality_studyid\series\sop.dcm)
    filename = Name_ID\Modality_StudyID\ SeriesID\Imageuid.dcm

  • HELP: Nightly Move Not Working

    So in a nutshell, the gui is not just a human-friendly representation of the dicom.ini and dgate monitor with a few keystroke saving features. It controls the automated/scheduled processes as well.


    Do you just recommend running the gui minimized at all times?


    Is this in the documentation?


    Thanks. I think we're getting close to fixing this for us! -Scott

  • HELP: Nightly Move Not Working

    If conquest is running as a service, why would the GUI need to be open? I never knew the GUI had to be up!


    Here's my settings:


    # Configuration of disk(s) to store images
    MAGDeviceThreshhold = 0
    MAGDevices = 2
    MAGDevice0 = Z:\dicom\incoming\
    MAGDevice1 = y:\dicom\
    NightlyCleanThreshhold = 0
    NightlyMoveThreshhold = 5000
    NightlyMoveTarget = MAG1


    Scott

  • HELP: Nightly Move Not Working

    Marcel, I figured out why the manual command-line dgate commands were not working: the -as5000 is in bytes, not kilobytes. When I changed it to -as5000000, it worked.


    Unfortunately, the "scheduled" nightly move still does not kick in. Did you ever check the Delphi code? Can I schedule a windows task to run the 2 commands?


    I appreciate your time. -Scott