DICOM services use a limited number of basic DICOM operations (officially called DIMSE operations), all of which are of course supported by DicomObjects.
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!)
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
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.
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
- If there are intervening firewalls
- (most severely) If the C-MOVE SCU connects to the SCP via Network Address Translation (NAT).
Despite all these problems, C-MOVE is the only retrieval protocol used by most PACS
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.
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.
These are themselves akin to simple database operations, and are used a “building block” for more complex services such as printing.
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.
This updates a single dataset, and requires the Instance UID of that dataset to be specified in the request. It is used in printing to “place” the images into the Image Boxes on the Film Box and is also used to update the examination status in the Modality Performed Procedure Step Service.
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.
This asks the SCP to delete a particular object
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.