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:
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:
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:
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.