DICOM and Database Functionality

DICOM

The DICOM standard has been established to facilitate data exchange between medical systems. It defines how the medical data must be encoded, and how they can be sent from an application on one computer to an application on a remote computer. DICOM basically consists of two components:

• Information Object Definitions (IOD): For each modality it defines a set of data fields. Some of them are mandatory, others are optional. This approach allows saving demographical and acquisition information together with the actual images.
• Communication protocol: DICOM has a client-server architecture. To send data from one host to the other the sender (client) must contact the potential receiver (server) whether it is ready to accept data. The server may reject the request because it has no space left, because the client is not allowed to send data, or because it does not understand the data to be sent. Otherwise it accepts the request and sends back a proposal how the data should be transmitted. The client then sends the data and gets an acknowledgment when the data have been correctly received.

PMOD is able to act both as a DICOM client and a server.

• The PMOD DICOM server allows clients such as a PET system to push images to PMOD. Additionally, it allows a user to query remote DICOM servers (such as imaging modalities or a Picture Archiving System) and fetch studies to process them locally.
• The PMOD DICOM client allows sending image data using the C-STORE communication to any DICOM server which has been entered in the PMOD configuration.

Database

The DICOM standard includes a description how DICOM data must be organized for off-line media such as CDs or DVDs. Basically, all the DICOM objects are stored in a directory tree, and a description of all stored studies must be written into a file called DICOMDIR at the root level of the directory tree. This approach is not suited for dynamically managed data, because the DICOMDIR file must be updated each time a study is removed or added, and because reading of the DICOMDIR is relatively slow.

To improve the performance when working with DICOM images, PMOD uses SQL databases to organize DICOM data access. The most important attributes of the DICOM objects like patient information, study and image descriptions as well as the file locations are stored in database tables. When the user needs to select image data, he is shown the information from the database tables which can very efficiently be searched and retrieved. After a study is selected, the file access information is immediately available to start the loading process.

Database Operation

If the database is configured, PMOD can save images and all other information types such as VOIs, transformations, kinetic modeling files etc. in the same manner as described for the DICOM objects:

A Save operation sends a request to the database containing all relevant meta-information about the data (patient name, study, series, data type, etc) and the data itself. The database server then saves the data into a directory structure and adds the access information into its tables.

When Load operations are performed, this access information is presented to the user in a way which allows to perform database searches, and if a data set is selected, it can be loaded into the PMOD tool using the internal access information.

Benefits of Using the Database

There are several benefits resulting from the use of the PMOD database:

• A unified user interface is shown when loading or saving all types of data.
• The searching process supports many filters and is very fast.
• Loading of the data itself, particularly the DICOM images, is fast.
• The databases can be shared over the network between different PMOD installations.