IMoveRequestHandler Failed: Bad request

Hi,

CMove command to Orthanc fails to download some CR images. But with Orthanc’s web viewer same images are correctly displayed and downloaded. Here is movescu output:

denis@brewery:~$ movescu -v -S -aec ORTHANC -aet brewery -aem brewery --port 11112 -od . pacs.viveya.local 4242 -k QueryRetrieveLevel=STUDY -k StudyInstanceUID=1.2.276.0.54.2017.18.13.392399

I: Requesting Association

I: Association Accepted (Max Send PDV: 16372)

I: Sending Move Request (MsgID 1)

I: Request Identifiers:

I:

I: # Dicom-Data-Set

I: # Used TransferSyntax: Little Endian Explicit

I: (0008,0052) CS [STUDY] # 6, 1 QueryRetrieveLevel

I: (0020,000d) UI [1.2.276.0.54.2017.18.13.392399] # 30, 1 StudyInstanceUID

I:

I: Received Final Move Response (Failed: UnableToProcess)

I: Releasing Association

Orthanc log:

I0804 14:01:45.093582 CommandDispatcher.cpp:491] Association Received from AET brewery on IP 192.168.66.6

I0804 14:01:45.094201 CommandDispatcher.cpp:689] Association Acknowledged (Max Send PDV: 16372)

W0804 14:01:45.094986 OrthancMoveRequestHandler.cpp:179] Move-SCU request received for AET “brewery”

I0804 14:01:45.095018 OrthancMoveRequestHandler.cpp:187] (0008,0052) QueryRetrieveLevel = STUDY

I0804 14:01:45.095037 OrthancMoveRequestHandler.cpp:187] (0020,000d) StudyInstanceUID = 1.2.276.0.54.2017.18.13.392399

E0804 14:01:45.096054 MoveScp.cpp:193] IMoveRequestHandler Failed: Bad request

I0804 14:01:45.096493 CommandDispatcher.cpp:892] DUL Peer Requested Release

I0804 14:01:45.096520 CommandDispatcher.cpp:899] Association Release

I can’t find anything strange in problem dicom files and in PG logs and I stuck… Other CR images from the same modality (same day) can be downloaded without any problems.

Hello,

This is compelling. Can you provide us with a relevant sample of the
dataset (possibly all of it, anonymized as necessary). We'd like to
attempt a repro and go from there.

Thank you!

Hi,

Sending an anonymized dcm file reproducing this error.

Hello,

cmove-test (3.03 KB)

Finally I found out the problem and fixed it. Somehow two different patients with different PatientID had the same StudyInstanceUID=1.2.156.112536.2.560.172241223131065181.1250813059906.25998 in PostgreSQL database (it seems someone had changed PatientID for a study and reloaded it to Orthanc). In this case Orthanc have no idea how to solve the ambiguity and fails with “Bad request” exception (it would be nice to have more informative request errors…). To diagnose the problem I checked PostgreSQL log after setting log_min_duration_statement = 0 in postgresql.conf. There I examed SQL queries and found the answer in this one:

orthanc=> SELECT d.id FROM DicomIdentifiers AS d, Resources AS r WHERE d.id = r.internalId AND r.resourceType=1 AND d.tagGroup=32 AND d.tagElement=13 AND d.value=‘1.2.156.112536.2.560.172241223131065181.1250813059906.25998’;

id


1214893

1216902

(2 строки)

I expected to get only one row, but had two. So I killed the worng study and it fixed my retrieve.
Thanks for help!
P.S. It would be nice to forbid Orthanc to have the same StudyInstanceUID for different PatientID’s and block cstore for this kind of duplicate studies.

I found an interconnected topic with my issue in Orthanc google group.