Adding *Time entries to dicom.sql

    Hi -


    I am trying to add some entries to the dicom.sql file. Specifically:


    { 0x0008, 0x0013, "InstanceCreationTime", 16, SQL_C_CHAR, DT_STR },
    { 0x0008, 0x0032, "AcquisitionTime", 16, SQL_C_CHAR, DT_STR },


    but after restarting the ConQuest server and re-initializing the database, the
    values can still not be retrieved. Should I be using SQL_DOUBLE or SQL_FLOAT
    instead of SQL_C_CHAR? Should something besides DT_STR be used?


    Also, I added:


    { 0x0018, 0x1020, "SoftwareVersion", 64, SQL_C_CHAR, DT_STR },


    and it works fine, but I was wondering if the length could be made longer than
    64 bytes? Some software versions are longer than that.


    Thanks,


    - Jim Irrer, Univ of Michigan Hospital ( irrer AT umich.edu )

    Hi,


    Time should be:


    16, SQL_C_CHAR, DT_TIME


    The length in the database can be set to anything you like (max 255 for dbaseIII). However, I try to keep the lenghts according to the DICOM standard: e.g., 16 for CS and 64 for LO. Some manufacturers do not keep to these lenghts though. Conquest does not care, and will truncate too entries longer as defined in dicom.sql with a warning.


    Marcel

    I tried the time as:


    { 0x0008, 0x0013, "InstanceCreationTime", 16, SQL_C_CHAR, DT_TIME }
    { 0x0008, 0x0032, "AcquisitionTime", 16, SQL_C_CHAR, DT_TIME },
    { 0x3006, 0x0009, "StructureSetTime", 16, SQL_C_CHAR, DT_TIME },


    but it did not work. I am using Pixelmed with a SERIES level query to get
    the data from the ConQuest server. The server version is:


    ConQuest DICOM server version 1.4.14. Date of this release: 20080902.


    But I'm guessing that that does not make a difference. If there are any other
    ideas I'd be glad to try them.


    Thanks,


    - Jim

    FYI -


    I got the following to work:


    { 0x300a, 0x0007, "RTPlanTime", 16, SQL_C_CHAR, DT_TIME },
    { 0x0008, 0x0033, "ImageTime", 16, SQL_C_CHAR, DT_TIME },


    so it looks like the syntax is right.


    Thanks,


    - Jim

    Sorry, but I don't know what is meant by 'read from sequences'. Is
    it that they are not indexed as part of the database key, or is it
    referring to how they are accessed?


    Is there some difference between the storage or access of RTPlanTime,
    which works, and InstanceCreationTime, which does not?


    Thanks for your responses,


    - Jim

    Hi Jim,


    Most RT objects data are stored in sequences, e.g.:


    Code
    (3006,0002) SH    [Long re ] # 8 StructureSetLabel

    (3006,0004) LO    [POI ] # 4 StructureSetName

    (3006,0008) DA    [20060323] # 8 StructureSetDate

    (3006,0009) TM    [164453] # 6 StructureSetTime

    (3006,0010) SQ    (empty) # 0 ReferencedFrameOfReferenceSequence

       (0020,0000) UL    64  # 4 ImageGroupLength

       (0020,0052) UI    [1.3.12.2.1107.5.1.4.49205.30000006032007250914000000247] # 56 FrameOfReferenceUID

       (3006,0000) UL    8376  # 4 RTStructureSetGroupLength

       (3006,0012) SQ    (empty) # 0 RTReferencedStudySequence


    You can only add information at the root, not inside the sequences (indented lines). However, the one you listed were not in a sequence - so I was wrong about that maybe being the problem.


    One thing why some items may not work is because the first 10 characters must be unqiue. So you may have to edit the database name to make it work.


    Also 0008,0032 is already there as AcqTime: so this explains why this one does not work. Can you otherwise post your dicom.sql that does not work?


    Marcel

    Ah - your note about only indexing root attributes makes sense. Non-root
    attributes might repeat.


    Yes, the failing entries were not unique in the first 10 characters of their
    names. I had assumed that the names had to match the entries in
    dgate.dic, but it looks like they don't, they just have to be unique.


    I changed the names so that they were unique, and it fixed the problem.


    before:


    { 0x0008, 0x0012, "InstanceCreationDate", 8, SQL_C_DATE, DT_DATE },
    { 0x0008, 0x0013, "InstanceCreationTime", 16, SQL_C_CHAR, DT_TIME },


    after:


    { 0x0008, 0x0012, "InstCrDate", 8, SQL_C_DATE, DT_DATE },
    { 0x0008, 0x0013, "InstCrTime", 16, SQL_C_CHAR, DT_TIME },


    Yay - Thanks so much for your help!


    I'm guessing that each query level of Patient, Study, Series, Image, and Worklist each
    are kept in a different table in the database, so that names only have to be
    unique within each. PatientBirthDate for example, is in each query level.


    - Jim

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login