Cannot know whether a C-MOVE was successful

[Tamás Sipos]

I'm initiating a C-MOVE operation from a Java application with dcm4che

assoc.cmove(UID.StudyRootQueryRetrieveInformationModelMOVE, 0x0000, atts,

    UID.ImplicitVRLittleEndian, localAE.getAETitle(), new DimseRSPHandler(assoc.nextMessageID()) {
        @Override
        public void onDimseRSP(Association as, Attributes cmd, Attributes data) {
            super.onDimseRSP(as, cmd, data);
            System.out.println(cmd);
        }
    });

to an Orthanc instance. Orthanc then successfully sends all DICOM objects of that Study to a modality.

My problem is however that I don't know whether the operation was successful because for some reason, onDimseRSP gets called one time only, after the first object has been sent, then no more, and the association is released.

I would expect it to at least wait for all C-STORE operations to complete and give me a final response according to the DICOM specs: ftp://dicom.nema.org/MEDICAL/dicom/2015b/output/chtml/part04/sect_C.4.2.2.html

But this is the only thing I get on the console:

(0000,0002) UI [1.2.840.10008.5.1.4.1.2.2.2] AffectedSOPClassUID
(0000,0100) US [32801] CommandField
(0000,0120) US [1] MessageIDBeingRespondedTo
(0000,0800) US [257] CommandDataSetType
(0000,0900) US [0] Status
(0000,1021) US [1] NumberOfCompletedSuboperations
(0000,1022) US [0] NumberOfFailedSuboperations
(0000,1023) US [0] NumberOfWarningSuboperations

If nothing else, at least knowing the NumberOfRemainingSuboperations would be great, so I could compare the number of objects to be sent with how many actually arrived, but not even this information is available.

[p.p...@synedra.com]

Well, you received a Success Response, after one image has been sent, and no warnings or errors occurred. If that is the only respnse yous SCP sends you, it is fine by the Dicom Standard, and you can conclude, that the C-Move operation ended successfully. You can read more on C-Move's response status values at [1]. So, from my point of view everything looks fine, it has nothing to do with dcm4che, though ;).

If you still suspect that dcm4che handles this incorrectly, I'd suggest to use Wireshark to see what is going on on the wire, and if you can find any differences.

[1] ftp://dicom.nema.org/MEDICAL/dicom/2015b/output/chtml/part04/sect_C.4.2.html

[Matthew Hill]

So.. couldn't you write an additional function that initiates a c-find to the c-store destination using the study info from the c-move
or do a cfind to both cmove and cstore targets?
Compare the returned image counts.

Bob's yer uncle.

(no fighting about who is or is not handling things correctly...)

-----Original Message-----
From: p.peer <p.p...@synedra.com>
To: dcm4che <dcm...@googlegroups.com>
Sent: Mon, Nov 26, 2018 1:09 pm
Subject: [dcm4che-group] Re: Cannot know whether a C-MOVE was successful

Well, you received a Success Response, after one image has been sent, and no warnings or errors occurred. If that is the only respnse yous SCP sends you, it is fine by the Dicom Standard, and you can conclude, that the C-Move operation ended successfully. You can read more on C-Move's response status values at [1]. So, from my point of view everything looks fine, it has nothing to do with dcm4che, though ;).

If you still suspect that dcm4che handles this incorrectly, I'd suggest to use Wireshark to see what is going on on the wire, and if you can find any differences.

[1] ftp://dicom.nema.org/MEDICAL/dicom/2015b/output/chtml/part04/sect_C.4.2.html

Am Montag, 26. November 2018 04:23:43 UTC+1 schrieb Tamás Sipos:

I'm initiating a C-MOVE operation from a Java application with dcm4che

assoc.cmove(UID.StudyRootQuery RetrieveInformationModelMOVE, 0x0000, atts,

    UID.ImplicitVRLittleEndian, localAE.getAETitle(), new DimseRSPHandler(assoc. nextMessageID()) {
        @Override
        public void onDimseRSP(Association as, Attributes cmd, Attributes data) {
            super.onDimseRSP(as, cmd, data);
            System.out.println(cmd);
        }
    });

to an Orthanc instance. Orthanc then successfully sends all DICOM objects of that Study to a modality.

My problem is however that I don't know whether the operation was successful because for some reason, onDimseRSP gets called one time only, after the first object has been sent, then no more, and the association is released.

I would expect it to at least wait for all C-STORE operations to complete and give me a final response according to the DICOM specs: ftp://dicom.nema.org/ MEDICAL/dicom/2015b/output/ chtml/part04/sect_C.4.2.2.html

But this is the only thing I get on the console:

(0000,0002) UI [1.2.840.10008.5.1.4.1.2.2.2] AffectedSOPClassUID
(0000,0100) US [32801] CommandField
(0000,0120) US [1] MessageIDBeingRespondedTo
(0000,0800) US [257] CommandDataSetType
(0000,0900) US [0] Status
(0000,1021) US [1] NumberOfCompletedSuboperations
(0000,1022) US [0] NumberOfFailedSuboperations
(0000,1023) US [0] NumberOfWarningSuboperations

If nothing else, at least knowing the NumberOfRemainingSuboperat ions would be great, so I could compare the number of objects to be sent with how many actually arrived, but not even this information is available.

--
You received this message because you are subscribed to the Google Groups "dcm4che" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dcm4che+u...@googlegroups.com.
To post to this group, send email to dcm...@googlegroups.com.
Visit this group at https://groups.google.com/group/dcm4che.
For more options, visit https://groups.google.com/d/optout.

[Gunter Zeilinger]

Actually, the C-MOVE SCP is responsible for finishing all C-STORE (sub-)operations, before sending the final C-MOVE-RSP with status 0 back to the C-MOVE SCU.

[Tamás Sipos]

"Actually, the C-MOVE SCP is responsible for finishing all C-STORE (sub-)operations,

before sending the final C-MOVE-RSP with status 0 back to the C-MOVE SCU."

Indeed. But since I'm no DICOM expert and maybe miss something, I don't want to file a bug for Orthanc,

and anyway, I cannot trust every PACS to work this way, so I guess the safest thing to do is to implement a C-FIND

to count the objects as Matthew suggested.

or if you have a better idea...

[p.p...@synedra.com]

I would not recommend C-Find Requests to double check, that the files have been sent for several reasons:

+ You can run into timing problems, when images were added on either machine, between the multiple C-Find and C-Move requests

+ The added overhead is not negligible, IMHO

+ It should not be necessary in the first place

As a rule of thumb, I'd suggest to stick to the Standard as long as you can. That also means that you should expect the applications you communicate with to behave correctly. In your case the PACS does: "Optionally, the SCP may generate responses to the C-MOVE with status equal to Pending during the processing of the C-STORE sub-operations. These responses shall indicate the Remaining, Completed, Failed, and Warning C-STORE sub-operations." [1]. In your case the PACS sent the one image too fast, that a pending response was not warranted for, or this particular implementation does not send them at all. Either way, the implementation is correct, as defined by the standard, because it did send the required final success response, which is also described in [1]. It sums up everything that has been/was supposed to be sent, which should provide you with enough information.

Only when there is a clear violation of the standard and it cannot be fixed on the other end, I resort to workarounds.

That said, it is common practice to send a C-Find request with user provided search criteria and present the responses to the user. Then, after the user selected what should be sent, the C-Move request is usually based on SOP instance UIDs (i.e. imeage UIDs). In that case you'd know beforehand how many images are supposed to be sent. You could use this to double check the values in the response, if you really need to.

HTH, Patrick

[1] Dicom Part 4 - C.4.2.3 C-MOVE SCP Behavior

[p.p...@synedra.com]

I just stumbled upon another Thread with a very similar question on the comp.protocols.dicom groupg [1], which explains that Orthanc's behavior seems to be indeed a bit outside of the Standard. So I guess in your case a workaround is in order. Or you could wait for the fix, which is due to be realeased [1].

As a side note, I think your question would have fit better on comp.protocols.dicom anyway ;).

[1] https://groups.google.com/forum/#!topic/comp.protocols.dicom/2Icxv2v9TNQ