Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Need help: C-MOVE with Offis imagectn

103 views
Skip to first unread message

Jim S

unread,
Dec 20, 2002, 8:06:21 AM12/20/02
to
I'm a DICOM newcomer trying to use the Offis imagectn to perform a
C-MOVE request and am running into a problem. Here are the steps I'm
doing:

1. Perform Patient-Root C-FIND to get all instances I may be
interested in. This is working fine, I have UID's for study, series,
SOP instances.
2. Select one of the SOP instances from the C-FIND and pass this into
a C-MOVE request. I am setting up my C-MOVE-RQ with the Study
Instance UID, the Series Instance UID, and the SOP Instance UID.

The problem is, imagectn does not issue a C-STORE command to the SCP
that I specify as the C-MOVE destination.

My C-MOVE-RQ is:
Command:
(0000,0000) Command Information: 92 [5Ch]
(0000,0002) Affected SOP Class UID: 1.2.840.10008.5.1.4.1.2.1.3
(0000,0100) Command Field: 33 [21h]
(0000,0110) Message ID: 4097 [1001h]
(0000,0600) Move Destination: MYSCP
(0000,0700) Priority: 0 [0h]
(0000,0800) Data Set Type: 1 [1h]
Dataset:
(0008,0018) SOP Instance UID:
1.2.826.0.1.3680043.2.547.2999.1.1.101
(0008,0052) Query/Retrieve Level: IMAGE
(0020,000D) Study Instance UID: 1.2.826.0.1.3680043.2.547.1999.1
(0020,000E) Series Instance UID:
1.2.826.0.1.3680043.2.547.2999.1.1

The above Study, Series, and SOP Instance UID's were returned to me by
a C-FIND command.

The values in C-MOVE-RP are:

(0000,0000) Command Information: 106 [6Ah]
(0000,0002) Affected SOP Class UID: 1.2.840.10008.5.1.4.1.2.1.3
(0000,0100) Command Field: 32801 [8021h]
(0000,0120) Message ID Being Responded To: 4097 [1001h]
(0000,0800) Data Set Type: 257 [101h]
(0000,0900) Status: 0 [0h]
(0000,1021) Number of Completed Sub-Operations: 0 [0h]
(0000,1022) Number of Failed Sub-Operations: 0 [0h]
(0000,1023) Number of Warning Sub-Operations: 0 [0h]

When I look at debug/verbose output of imagectn, it says at one point:
DB_HierarchicalCompare : No UID Key found at level 0

This is my first time trying to use C-MOVE, and I'm not really sure
that I'm doing it correctly. Can anyone help me with what I'm doing
wrong?

Jim S

unread,
Dec 30, 2002, 1:39:54 PM12/30/02
to
As might be expected, a few days of trial and error solved the problem
for me.

As it turns out, I assumed that entering just a UID would cause
imagectn to be able to do the C-MOVE. However, as implied in the
spec, I need to put all the same fields which were required by C-FIND
into the C-MOVE request -- not just the single UID field (even though
this field by itself *should* be sufficient to specify the composite
instance I want).

Jim S

unread,
Dec 31, 2002, 9:01:04 AM12/31/02
to
I have experimented a bit more and found that my last post was not
totally accurate. All of the query fields are not required. It seems
that the Patient ID, Study Instance UID, and Series Instance UID
fields are the ones required by imagectn for retrieving composite
instances using C-MOVE.

When I omit these fields, I get no image. If I put zero-length values
into these fields, then I get the image(s) I want.

Here are example datasets used with my C-MOVE-Request:

This works:
(0008,0018) SOP Instance UID: 1.2.840.13719.2.25.1.157
(0008,0052) Query/Retrieve Level: IMAGE
(0010,0020) Patient ID:
(0020,000D) Study Instance UID:
(0020,000E) Series Instance UID:

This does not work:
(0008,0018) SOP Instance UID: 1.2.840.13719.2.25.1.157
(0008,0052) Query/Retrieve Level: IMAGE

Jim S

unread,
Dec 31, 2002, 2:48:33 PM12/31/02
to
One final post -- just in case any future DICOM newcomers also have a
bit of trouble with C-MOVE.

The PatientID, StudyInstanceUID, SeriesInstanceUID, and SOPInstanceUID
are listed as 'U' in the specification. 'R'=required , 'O'=optional,
'U' = unique key. I had originally misunderstood the meaning of 'U'.
There is a single 'U' item at each query level (PATIENT, STUDY,
SERIES, IMAGE). Even though the Unique Key Attribute for the IMAGE
level could be enough for a C-MOVE command to locate a single
composite instance, the unique key attributes for all the upper levels
in the hierarchy must be there. They are sort of like type-2 values
when it comes to a C-MOVE

Alright... enough posting on this subject for me.

0 new messages