DIMSE

The C-STORE command initiates the transfer of a single DICOM SOP Instance from a Service Class User (SCU) to a Service Class Provider (SCP). It is the fundamental operation for sending images from a modality to a PACS archive. The command includes the SOP Class UID and SOP Instance UID to uniquely identify the object being stored.

• Workflow: A CT scanner (SCU) sends reconstructed slices to a central PACS server (SCP).
• Confirmation: The SCP returns a C-STORE-RSP with a status code (e.g., 0x0000 for Success) after verifying data integrity.
• Storage Commitment: Often followed by a separate N-ACTION request to confirm the SCP has taken permanent custody of the image.

The C-FIND command performs a hierarchical search against the SCP's database using a set of matching key attributes. The SCU sends a request containing populated DICOM Tags as search criteria, and the SCP returns a sequence of matching identifiers.

• Query/Retrieve Levels: The search scope is defined by the Query/Retrieve Level (Patient, Study, Series, or Image).
• Matching Keys: Supports single-value matching, universal matching (empty value), and range matching for date/time attributes.
• Use Case: A radiologist's workstation queries the PACS for all CT studies for a specific patient performed within the last year.

The C-MOVE command instructs the SCP to initiate a new C-STORE sub-operation to transfer all matching SOP Instances to a third-party destination Application Entity Title (AET). The SCU specifies the retrieval destination, and the SCP acts as a temporary SCU to push the images.

• Three-Party Operation: Involves the requesting SCU, the source SCP, and the destination AET.
• Status Updates: The SCP sends pending C-MOVE-RSP messages for each transferred instance, allowing the requester to track progress.
• Contrast with C-GET: Unlike C-GET, the data channel does not need to traverse the same association as the command channel.

The C-GET command retrieves SOP Instances directly over the same DICOM Association used for the request. The SCP sends the matching images back to the requesting SCU on the existing connection.

• Simplified Firewall Traversal: Only requires a single outbound connection from the SCU, making it preferable for teleradiology across firewalls compared to C-MOVE.
• Negotiation Requirement: Both the C-GET SCP role and the required C-STORE SCP role must be successfully negotiated during Association Negotiation.
• Behavior: The SCP pushes images using C-STORE sub-operations on the open association.

The C-ECHO command implements the DICOM Verification SOP Class. It is a simple ping-like mechanism used to confirm network connectivity and basic DICOM compliance between two Application Entities before initiating clinical operations.

• Handshake: The SCU sends a C-ECHO-RQ, and the SCP responds with a C-ECHO-RSP containing a Success status.
• No Data Transfer: No SOP Instances or patient data are exchanged; it strictly validates the association layer.
• Troubleshooting: Often the first step in debugging a failed DICOM integration to verify that the IP, port, and AET configurations are correct.

The C-CANCEL command allows an SCU to request the graceful termination of an outstanding C-FIND, C-MOVE, or C-GET operation. It prevents the SCP from continuing to process a long-running or erroneous query.

• Graceful Termination: The SCP stops sending pending responses and issues a final response with a status of 0xFE00 (Canceled).
• Resource Management: Critical for preventing a typo in a C-FIND query from locking up the SCP's database resources.
• Message ID: The C-CANCEL request must reference the Message ID of the original operation to be terminated.