Browse Prior Art Database

Optimization of DICOM C-MOVE Requests

IP.com Disclosure Number: IPCOM000020652D
Original Publication Date: 2003-Dec-08
Included in the Prior Art Database: 2003-Dec-08
Document File: 2 page(s) / 48K

Publishing Venue

IBM

Abstract

SCP-B performs a large expensive query which may entail also use of significant amount of its resources in CPU time, memory space and I/O with the magnetic disk subsystem, or even the backup secondary storage subsystems. Eventually, when SCU-B contacts SCP-C, most of the work done is wasted since most of the objects prepared for transmission cannot be sent but will be rejected by SCP-C.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 48% of the total text.

Page 1 of 2

Optimization of DICOM C-MOVE Requests

Digital Image and Communication in Medicine (DICOM) is a standard for managing medical images. The standard includes a model for organizing medical objects (specifically images) in repositories, format of medical images, and communication protocols for exchanging medical images. The documents of this standardization body can be found in http://medical.nema.org/. Common scenarios for the use of DICOM protocol are in hospitals and medical service providers. Images are generated on modalities such as CT, MRI, and US, and transmitted to image repositories which are termed PACS (for Picture Archival and Communication System). PACS collects the images, provides them to reviewing work-stations where radiologists diagnose them, and saves long-term histories of images on long-term storage media and devices.

    The DICOM communication protocol defines several classes of services, and two roles of participants. A service class user (SCU) is an application on a computer which acts as a client (in the classical client-server model). A service class provider (SCP) is an application on a computer which acts as the server for the specific service. In our typical scenario, an imaging modality that stores an image in a PACS acts as the SCU for the storage service class, of which the PACS station acts as the SCP. Storing an image by one station in a second machine is the C-STORE service class. Other service classes that are relevant to our problem area are C-FIND by which the client performs a query on the repository provider, C-ECHO by which a client verifies that a provider is active, and C-MOVE by which a client requests to transfer images - which answer a certain query - from the provider to a third party. This invention deals with optimizing the execution of C-MOVE services in the DICOM protocol.

    There are 3 parties involved in a C-MOVE service; A is the client initiating the request, B is the server performing the service, and C is a third party, server which receives the images. B is an image repository manager (i.e., PACS). The roles played by these actors are: A acts as an SCU that we term SCU-A. B acts in both roles of SCP and SCU that we term SCP-B and SCU-B. C plays the role of an SCP that we term SCP-C. The C-MOVE service is started by SCU-A, which sends message to an image storage server SCP-B, specifying a query and requesting to transmit one or more images (which answer that query) to another image storage server SCP-C. The later may also be a temporary storage server such as a display work-station (or even a component of the same application which plays the role of SCU-A). SCU-B sends images to the SCP-C using the C-STORE service class, playing the nested role of an SCU since it is done while serving a C-MOVE request as an SCP.

    The problem with the C-MOVE protocol lies in the DICOM protocol semantics which creates performance pitfalls as follows. The initial step in a DICOM interaction is setting u...