Rationale and Objectives: The exchange of radiological images is defined by the DICOM standard (Digital Imag-ing and Communication in Medicine), the exchange of textual information by the HL7 standard (Health Level Seven). Within the meaning of a workflow approach, both standards have been refined and integrated into IHE (Integrating the Healthcare Enterprise) since 1998. However, many older imaging modalities do not support these integration profiles. In some cases, such modalities create DICOM objects that can be used within the IHE context but only with constraints. The following difficulties can arise from the incorrect implementations of the standards: Imaging modalities may:
These difficulties can often be solved by modifying the data elements or by deducing their contents from other elements. Manipulation of data elements can also improve use cases that are not defined in IHE.
From analysis of the workflow of the PACS, the described difficulties can be divided into three abstract functional domains: 1) In a PACS, images acquired by the modalities are transferred between archive and workstations in a closed world. 2) Teleradiology can connect two or more PACS. 3) Images leave the PACS typically as film prints or as image media in the form of DICOM CD-Rs that allow a standardized image import also. To allow correction of the DICOM objects, a suitable device has to connect to an existing channel between two PACS devices. In case of import and export, such a device provides routing functionalities between two subnets, which also give the project its name. To achieve the highest possible degree of flexibility we developed a processing device as a toolbox of functions that can perform data modifications automatically and unattended.
Materials and Methods: First, the DICOM objects are received by one of three receivers. The first input channel can directly receive images from the PACS via network. The router provides the DICOM service Storage as Service Class Provider. From the view of the PACS this makes the router a node for receiving images. The user can select between two modes of transmission: Open transmission or TSL (Transmission Layer Security) encrypted. Both types are defined in the DICOM standard. The second input channel allows the access to storage media formatted according to part 12 of the DICOM standard. Specifically, these are DICOM CD-Rs. Using the third channel, the toolbox can access files stored on the local file system of the computer where the toolbox is running. These files must contain DICOM objects and must have a file structure according to DICOM part 10.
Independent of the channel receiving a DICOM object, it is decoded into an abstract data structure and queued into the processing pipeline of the toolbox. The processing pipeline is realized by a sequence of plugins. Each plugin represents a self-contained program segment that can perform a clearly defined task. It receives a data package from a receiver or from the preceding plugin, processes the package and passes it on to the next plugin in the pipeline. After all steps of the processing pipeline have been finished, the data package is sent to its addressees. For this, various senders are available; each sender exists as a plugin. Thus, it is possible to send data packages consecutively via various output channels to multiple receivers. Functionally, the DICOM Router provides the complementary channels to the receivers. The system was designed to run multiple pipelines simultaneously. For each request, a configuration file defines an inherent processing pipeline including the receiver. The functionalities of the DICOM Router are implemented as a program library. To use this library it is necessary to run programs, so called frontends, for the different applications. As two possibilities a command line frontend and one with a graphical user interface are included in the project.
Internally, the program architecture of the DICOM Router has a multi-layered hierarchy.
This has the advantage that the user does not need detailed knowledge of the processes of DICOM communication or of the internal details of the plugin to adapt functionality. The user just looks at the upper program layer of the DICOM Router, which consists of the graphical user interface of the selected frontend and a configuration file. For example, Listing 1 shows an excerpt of a configuration file for a specific use case. Since it is a text file, the user can change the values of the attributes of the plugins by means of a simple text editor.
The software was developed in Java (version 1.4). The DICOM functionality is completely encapsulated in the dcm4che library that also supports the "DICOM Secure Transport Connection Pro-files" for encrypted communication channels. The use of this library as a lower layer has the advantage that all higher layers must only handle abstract DICOM structures. This applies to the program frontends, the receivers and the plugin components. Each plugin is represented by its own Java class. To allow an easy implementation of new functionalities, a simple programming interface is defined for the plugins. By copying compiled plugins to a predefined subfolder of the DICOM Router, the plugins are immediately available to the processing pipeline without re-linking the whole project. Currently, the plugins listed in Table 1 are implemented and fulfill specialized functions needed to correct for the three situations described in the introduction. More com-plex functions can be achieved by the XSLTransformPlugin. In contrast to the other plugins, this one does not have its own processing routine. Rather, it is supplied by an external text file as an XSL-template (eXtensible Stylesheet Language). This concept provides the opportunity for the user to program new functionalities, even if they require complex combinations of elements of the DICOM object. Before applying the XSL template the DICOM object is translated into a XML (eXtensible Markup Language) document. This enables an easy conversion of the DICOM object into other file formats that can be saved to the local file system. For example, one of the XSL templates implemented in the project exports DICOM objects as HTML files. For logging program output, the library log4j is used. Instead of writing logging output to the local screen, this library can also store the logging information as local files or send it to any computer connected to the network. Computer hardware requirements are that of the Java runtime environment: at least a Pentium II processor with a clock speed of 400 MHz and random access memory of 256 MB. The hard disk capacity relates to the requirements of the plugins used. The main program components of the DICOM Router need a disk space of 1.5 MB only.
The user manual is available http://sourceforge.net/projects/dcmrouter/ as a PDF file.
You can download the software for free at http://sourceforge.net/projects/dcmrouter/ .
The project has been published as a open source project under the GNU General Public License (GPL).