Posts by irrer

  • Problem connecting to Varian

    I have to go through special channels to get the ConQuest logs, but once I did they pointed out that Varian was
    denying the connection, and it was not a fault with the data. This is quite clear and ConQuest did exactly what it should.


    Key message:


    20170210 14:03:17 Host 'ROCITRIXDEV02' did not accept the connection


    Adding ConQuest to that Varian instance fixed it.


    Here is the pertinent ConQuest log :





    Thanks - Jim

  • Problem connecting to Varian

    When the files were sent to a different PACS and then imported into the planning system (Varian Eclipse) they
    worked fine, so it looked like ConQuest was the problem. ConQuest appears to add the group lengths while the
    other PACS don't, so I assumed that they in turn were the problem, though this reasoning could be faulty.


    The planning system emits the vague error message:


    S003: (W) 2017/02/07 14:50:34.185 [14240] Move failed or incomplete.


    which tells me nothing.


    So it looks like there is a special case of incompatibility for this particular file between ConQuest and Varian, which
    means that it is impossible to definitively attribute the problem to either side.


    Sorry for wasting your time - Jim.

  • Problem connecting to Varian

    I've been having a problem with Conquest where when files are C-STORE'd to
    Conquest, they are modified. In particular, the following 6 attributes are added:


    0008,0000
    0010,0000
    0018,0000
    0020,0000
    0028,0000
    7FE0,0000


    Attempts to import them into our treatment planning system fails.


    I've attached one slice of the series before and after to show the difference. As a
    convenience, there is also a text listing for before and after versions, and another
    text file showing the differences.


    Is there something wrong with DICOM or maybe a workaround?


    FYI, we generated the files using ITK. Fields before anonymization:


    0002,0013 SH 1 ImplementationVersionName : GDCM 2.0.17
    0002,0016 AE 1 SourceApplicationEntityTitle : GDCM/ITK 4.4.2


    The version I'm using is 1.4.17, released 20130517. Maybe a newer version fixes this?


    Thanks for any insight - Jim

  • ConQuest inserts new UN attributes into a DICOM file

    I've just been informed by Dr. Clunie that :


    Quote

    Those attributes that Conquest is inserting are just group length
    attributes; historically irrelevant but not illegal, and harmless
    (as long as they are populated with the correct values).


    So its not a problem.


    Sorry for the false alarm - Jim

  • ConQuest inserts new UN attributes into a DICOM file

    Greetings -


    I have been working with Dr. David Clunie's Pixelmed toolkit, and had problems uploading files to some PACS.


    The problem was resolved for the other PACS by changing the Pixelmed toolkit to adopt the strategy proposed
    by CP1066 (reference below), but upon closer examination I found that Conquest was introducing UN attributes
    into the file.


    I have posted the 'before' and 'after' versions of the file with text versions to aid ease of understanding at:


    http://www-personal.umich.edu/~irrer/ConQuest/


    So far this has not created any problems for us, but I thought it might introduce problems for some
    systems and wanted the ConQuest community to be aware of it.


    FYI - I also C-MOVED the file from a different PACS to ConQuest and observed the same result.


    BTW - I am using ConQuest DICOM server version 1.4.17. Date of this release: 20130517


    http://www.dclunie.com/dicom-status/status.html#CP1066


    http://iopscience.iop.org/0031-9155/51/5/L01/


    Thanks - Jim

  • Adding *Time entries to dicom.sql

    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

  • Adding *Time entries to dicom.sql

    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

  • Adding *Time entries to dicom.sql

    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

  • Adding *Time entries to dicom.sql

    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

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

  • MSServer2003/MSSQL2005 SSL Provider error with GUI brower

    Found with dicomserver1414, if you specify a name in the "Local unique name of this server" field on
    the "Configuration" tab, and that name is not in the "Known DICOM providers" list on startup, then you will get the
    error described:


    ottf on Thu Dec 06, 2007 3:54 am
    Hmmm.....


    Now I get error:


    Access violation at address 004D9379 in module 'conquestdicom server.exe'. Read of address 00000000.


    EDIT: sorry for that :)


    Seems to work correctly on servers that are not dicom forwarders.