Virtual PACS does not work for some clients [1.5.0d]

    Hello,


    I have an installation where Conquest server is working as a gateway for other PACS server. Problem is it is working beautifully but only for some clients. i.e. the findscu client will get the list of studies from the virtual PACS correctly but I have another client (a workstation program) that will find only local studies on the Conquest server while I believe the settings are the same. I have tried all possiblie configurations of the VirtualServerFor0, VirtualServerPerSeries0, CacheVirtualData, OverlapVirtualGet settings but with no change.


    How can I approach this problem? I am attaching my dicom.ini file and logs from correct operation (findscu-log.txt) and the failing search on workstation (rover-log.txt).


    Thank you very much for your help and a great program. I have used it several times in various scenarios during the years. All best! Pavel

    Hi Pavel,


    Thanks for the nice works and very good information. The query from ROVER is strange, it queries at STUDY level but asks for SERIES level information. Maybe the PACS refuses to answer. Can you query PACS directly from ROVER? The log is consistent with PACS returning zero items.


    Marcel

    Hi,


    You were right. After much testing it seems it is a bug in the ROVER software. It will not connect to the PACS directly either. I guess Conquest is more forgiving than the real PACS. What threw me off is that there is a windows version and linux version and apparently the bug is only in the linux version of the software.


    Is there a way how to "rewrite" the query in the Conquest on the fly so that it would successfully query and retrieve from the real PACS? Because otherwise I will have to write some automation to move the studies beforehand from the PACS to Conquest for the software to find it and that will be quite cumbersome.


    In addition to what ROVER calls "Study Root Information Model" - logs from which I have presented previously, there is also an option for "Patient Root Information Model", with or without "Acceleration". I am uploading these logs now. These settings do not work with PACS either.


    Thank you again for your help. Pavel

    Hi,


    you can play with QueryConverter0 to rewrite the query. Maybe best do it in lua, e.g.


    QueryConverter0 = lua/rewritequery.lua


    Then you have ample space to add lots of logic, e.g.


    rewritequery.lua

    Code
    if Associated.Calling == 'ROVER' then

      Data.QueryRetrieveLevel = 'IMAGE'

    end


    Marcel

    Hi,


    This did not work. It will return a list of images but only for studies that are local on Conquest. It will not find anything on virtual PACS still.


    Digging in the sample files in lua/ I can now issue the query to PACS successfully from the script, but how would I pass the result to the caller (b in the code below)?

    Code
    if Association.Calling == 'ROVER' then

      a=DicomObject:new()

      a.QueryRetrieveLevel='STUDY'

      a.PatientName=Data.PatientName

      a.PatientID=Data.PatientID

      a.StudyInstanceUID=''

      a.StudyDate=Data.StudyDate

      b=dicomquery('CONQUESTSRV1', 'STUDY', a)

      print(b[0].PatientName)

    end

    Thanks. Pavel

    Hi Pavel,


    It think indeed that QueryConverter only modifies local queries. I think I need to add events VirtualQueryConverter and VirtualMoveConverter for you to be able to solve your problem.


    Marcel

    I’ve encountered similar issues before. It sounds like a configuration problem between the clients. Make sure both clients have identical DICOM query settings and AE Titles. Sometimes, even minor differences can cause this issue. Also, double-check your dicom.ini settings, especially the VirtualServerFor0, VirtualServerPerSeries0, CacheVirtualData, and OverlapVirtualGet parameters.

    Analyzing the logs (findscu-log.txt vs. rover-log.txt) for differences in DICOM messages might provide clues. If you can do it to accelerate vps, post your dicom.ini file and the logs here. It’ll be easier to pinpoint the problem.

    It sounds like the issue might be due to differences in the client configurations or network permissions. Please ensure both clients have identical DICOM query settings and correct AE Titles. Check for any discrepancies in the logs you provided, especially differences in DICOM messages. Also, review your dicom.ini settings for any possible errors.

    Hello Marcel,


    I have tried it with VirtualServerQueryConverter0 but no dice. The only change I can see is that there is now a

    Importconverter0.0: dofile(Global.basedir..'lua/rewritequery.lua')

    line in the attached log file. Why Importconverter? Shouldn't it be QueryConverter?


    Also I have tried to free the Data object and create it anew with DicomObject:new() but no change either. It seems to me that the query object is separate from Data object so I am not able to do anything with it.


    I am at a loss now and do not know how to follow. Yeah, the ROVER program is not fully DICOM compliant and the real PACS rejects its queries. That would be a perfect use case for virtual PACS in my opinion -- to do the compliant query on its behalf. To fix it I need to either pass the results from in-script query back or have a complete control over the query Conquest is seemingly sending unchanged now.


    All best, Pavel

    Hi,


    you can use Data:Reset() in a recent version to empty it, and then you can put in your own entries. But you cannot delete Data as it is built-in.


    Can you post your dicom.ini?


    Marcel

    Marcel van Herk is developer of the Conquest DICOM server together with Lambert Zijp.

    Edited once, last by marcelvanherk: Changed method name ().

    Hi,


    Data:Reset() gives me


    *** lua run error ./lua/rewritequery.lua:8: attempt to call method 'Reset' (a nil value) in 'dofile(Global.basedir..'lua/rewritequery.lua')'


    dicom.ini and log are attached.


    Thanks! Pavel

Participate now!

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

Register Yourself Login