Bug Report: C-MOVE Success Responses Without Suboperation Counters Cause Move Processing to Stop

[CS Tima]

Summary

We identified an interoperability issue between OpenREM and a DICOM Q/R SCP implementation (Philips Intellispace CardioVascular).

OpenREM successfully performs the C-FIND operation and correctly identifies all matching RDSR series. However, during the subsequent C-MOVE phase, processing stops after the first series although additional series remain to be retrieved.

The issue appears to be caused by a valid C-MOVE Success response that does not contain the optional suboperation counters.

Environment

• OpenREM version: 1.0.0b2

• DICOM Q/R SCP: Philips ISCV

Observed Behaviour

OpenREM successfully:

1. Establishes the association

2. Performs C-FIND requests

3. Receives all expected matching series

4. Starts the first C-MOVE request

The SCP returns:

C-MOVE-RSP Status = Success (0x0000)

However, the response from Philips ISCV does not contain:

• NumberOfCompletedSuboperations (0000,1021)

• NumberOfFailedSuboperations (0000,1022)

• NumberOfWarningSuboperations (0000,1023)

Example decoded response:

DICOM, C-MOVE-RSP ID=1 (Success) (0000,0900) Status Success (0x0000)

No suboperation counters are present.

Comparison With Other PACS

We compared the behaviour against other systems (Synedra eArchive and Phoenix Merlin PACS).

Those systems return:

Status = Success (0x0000) NumberOfCompletedSuboperations = 1 NumberOfFailedSuboperations = 0 NumberOfWarningSuboperations = 0

OpenREM processes all series correctly against those systems.

Root Cause Analysis

The relevant code in qrscu.py uses:

completed_sub_ops = getattr( status, "NumberOfCompletedSuboperations", None ) failed_sub_ops = getattr( status, "NumberOfFailedSuboperations", None ) warning_sub_ops = getattr( status, "NumberOfWarningSuboperations", None )

Later these values are accumulated:

query.move_completed_sub_ops += completed_sub_ops query.move_failed_sub_ops += failed_sub_ops query.move_warning_sub_ops += warning_sub_ops

When the SCP omits the suboperation counters, the values become None.

In our testing, processing stopped after the first successful move response.

Proposed Fix

Treat missing suboperation counters as zero.

completed_sub_ops = getattr( status, "NumberOfCompletedSuboperations", 0 ) or 0 failed_sub_ops = getattr( status, "NumberOfFailedSuboperations", 0 ) or 0 warning_sub_ops = getattr( status, "NumberOfWarningSuboperations", 0 ) or 0 Validation

After applying the above change:

• OpenREM continued processing all remaining series.

• Multiple sequential C-MOVE requests were executed successfully.

• Retrieval completed as expected against the ISCV SCP.

Example log output after the fix:

Requesting move: study 1 of 3 Requesting move: study 2 of 3 Requesting move: study 3 of 3

Prior to the fix, processing stopped after:

Requesting move: study 1 of 3 Conclusion

The issue appears to be triggered by a DICOM SCP that returns a valid final C-MOVE Success response without suboperation counters.

While the SCP behaviour may be unusual, OpenREM can be made more robust by treating missing suboperation counters as zero rather than None.

[Ed McDonagh]

Thank you for this comprehensive report and fix. When I get gitlab properly up and running I will add it there so we can incorporate it into the main code. Unless you want to have a go at adding the issue?

https://gitlab.com/groups/openrem/-/work_items

I think if you have a gitlab account you should be able to do that, I'd like to know!

Kind regards

Ed

--
You received this message because you are subscribed to the Google Groups "OpenREM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openrem+u...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/openrem/b2fdf8db-55d7-4e1d-bf10-8fcb2b1dae0cn%40googlegroups.com.