Contents

Composite Operations

These are "self-contained", and the objects passed therefore contain enough information for the operation to exist independently, without reference to other operations on the same or different associations (though of course they are commonly used as part of more complex operations!)

C-STORE

The most basic DICOM operation, otherwise known as "DICOM Push" allows an SCU to send a Composite_Instance to an SCP. For instance, it is used to send images from a modality to PACS or create the delivery mechanism for C-MOVE

C-FIND

Initially used as part of the Query/Retrieve service, but subsequently re-used in the Modality_Worklist and General_Purpose_Worklist services, this is a very simple operation rather akin to a SQL query, whereby a dataset is passed from the SCU to the SCP containing 2 sorts of attribute:

Those which need to be matched (equivalent to the WHERE clause of SQL)

These have "filled in" values

Those to be returned to the SCU (equivalent to the SELECT clause of SQL)

These are sent a blank fields.

The SCP responds by sending a number of matching datasets, followed by a "complete" response to say that it has finished.

C-MOVE

This requests the C-MOVE SCP to act as a C-STORE SCU and to copy composite_instances to a requested AET which may or may not be the original C-MOVE SCU (99% of the time it is!). This operation has multiple problems:

Only the AET may be specified in the request (not an IP address/port number), so it can only work if the SCP has this information pre-programmed into its data tables (and many companies charge for adding such entries!)

The C-MOVE SCP must be able to make a TCP connection to the end point (normally the C-MOVE SCU), but several things can make this impossible:

If the SCU has a dynamic IP address (using DHCP) to the server does not "Know" it

Despite all these problems, C-MOVE is the only retrieval protocol used by most PACS

C-GET

C-GET is like C-MOVE, but instead of using a secondary Association, the requested Composite_Instances are sent over the original association. This avoids all the problems described above for C-MOVE. There are 2 downsides to C-GET:

The SCU must know in advance what SOP classes it is to receive over the association, as it must negotiate suitable Presentation_Contexts for them. This information should be obtainable via C-FIND.

It is little used by the large PACS manufacturers, possibly due to the first of the points above regarding the C-MOVE lookup table.

C-ECHO

This is a basic "is everything working OK" service - sometimes referred to as "DICOM Ping". It should not be confused with a basic ICMP ping however as it is a full-blown DICOM service, using full negotiation, and therefore tests more than simple IP connectivity. Support for C-ECHO is mandatory for all Application_Entities which accept associations.

Normalised Operations

These are themselves akin to simple database operations, and are used a "building block" for more complex services such as printing.

N-CREATE

This creates a dataset within the SCP for subsequent use. The Instance_UID may be specified by the SCU or if left blank is provided by the SCP.

N-GET

This requests a single dataset, and requires the Instance_UID of that dataset to be specified in the request. In some cases (e.g. printer status) that UID may be a "Well-known_UID"

N-ACTION

This asks the SCP to "do something". The common uses are printing a film, and checking the status of image storage as part of Storage_Commitment.

N-DELETE

This asks the SCP to delete a particular object

N-EVENT-REPORT

This is an unusual operation as it is defined to be sent from an SCP to an SCU. It was initially used for printer updates (e.g. alerting the SCU/user of a film jam), but has subsequently been used in other services such as Storage_Commitment.