DICOM query error: No dataset received

    Hi, I'm trying to query a remote system from the Conquest GUI (Win32), and get the following error:


    Quote

    DICOM query error (patient ID = ) : No dataset received


    The remote system is a GE Advantage Workstation, and it can be queried properly from the same PC using findscu:



    The remote system can push to conquest properly, but cannot pull, presumably due to the same problem.


    I guess I must have something set up wrong, but just can't figure out what it is. I did try the Debug settings, and there was no information -- not even a record that the query failed.

    Can you send images to the GE? If not, the GE might not accept the calling or called AE of the server for incoming requests. Otherwise it might not support a patientroot query, you might try a studyroot one. Also, it might not accept all wildcards for the query. The GUI function does not use the server at all for querying a remote system, therefore there is no log.


    Marcel

    Thank you Marcel.


    Quote from marcelvanherk

    Can you send images to the GE? If not, the GE might not accept the calling or called AE of the server for incoming requests.


    Using findscu, I see that GE seems to ignore the calling AE, but does require the correct called AE. You are correct to assume that Conquest also can't send images. But it can receive if I sit at the GE and push.


    Quote

    Otherwise it might not support a patientroot query, you might try a studyroot one.


    Here you are also correct. The Conquest error message above was for Query level of "STUDY - StudyRoot". When I use "PATIENT," Conquest simply hangs (until timeout).


    Quote

    Also, it might not accept all wildcards for the query.


    Wildcards seem to be ok using findscu.


    -Greg

    Yes, the AE seems to be correct. Using ethereal, I see that GE accepts the Dicom association request. Then Conquest sends the data request, and GE responds with a failure notice. Then they release.


    I have a few hypotheses, but I will only propose one to start. I noticed that findscu returns no data if I omit the "-k 0020,000D=" option. When I looked through the conquest packets, I didn't find this key in the data request. Maybe that is why.


    A final note: I found I can use K-Pacs to query GE and transfer from GE to Conquest. Though I guess this is not surprising if it is dcmtk.

    I didn't know about this setting. Now that I know it exists, I found it in the manual...how embarassing.


    By changing this setting, communication (mostly) works. I can sit at conquest and push to GE. I can sit at GE and pull from conquest. Neither of these worked before.


    I say (mostly) because unqualified queries still do not work. If I fill in a Patient Name or Patient ID, then I get a list. But if I leave all the fields blank (or use only the global wildcard "*"), I get this message:


    Quote

    "*** DICOM query error (patient ID = ) : Incomplete server-response


    This, however, is just a minor irritation, and otherwise things seem to be ok. Thank you so much for your help!


    -Greg

    Hi,


    according to the dicom standard, every query response should list the same amount of items, and the ones that are not availble for a particular response (e.g., study) should be empty. Our interface uses that specification, but we are finding that more and more systems do not do that. They skip empty items. Our (very simple) query engine does not handle this correctly and gives the message.


    From the standard:


    C.4.1.1.3.2 Response Identifier Structure
    The C-FIND response shall not contain Attributes that were not in the request or specified in this
    section.
    An Identifier in a C-FIND response shall contain:
    — Key Attributes with values corresponding to Key Attributes contained in the
    Identifier of the request.
    Notes: 1. All Required Keys in the Request Identifier, as well as all Optional Keys in the
    Request Identifier that are supported by the SCP, will therefore be present in the
    Response Identifier.
    2. Required Keys and supported Optional Keys in the Response Identifier will
    have zero length if the SCP has no value to send    ; i.e., there is no requirement
    that the SCP have a value for these, or create a dummy value.


    We complained to our manufacturer (Kodak) about a year ago, but off course have not had an answer.


    Marcel

    Thanks Marcel,
    I'm guessing you wish to keep Conquest DICOM compliant and leave the code as is. I have noticed that I can query and retrieve using K-PACS. Is the request in this software a bit more accommodating? I thought they used the same mechanism.
    I have other issues with KPACS, and would prefer to use Conquest.

Participate now!

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

Register Yourself Login