DOI: 10.1148/rg.256055072
RadioGraphics 2005;25:1709-1721
© RSNA, 2005
Informatics in Radiology (infoRAD)
An Open Source Framework for Modification and Communication of DICOM Objects1
Thomas Hackländer, MD, MSc,
Jens Martin, MSc and
Klaus Kleber, MSc
1 From the Department of Radiology, HELIOS Klinikum Wuppertal, Hospital of the University of Witten-Herdecke, Heusnerstrasse 40, 42283 Wuppertal, Germany (T.H.); and VISUS Technology Transfer, Bochum, Germany (J.M., K.K.). Presented as an infoRAD exhibit at the 2004 RSNA Annual Meeting. Received March 28, 2005; revision requested June 23 and received July 13; accepted July 18. All authors have no financial relationships to disclose.
Address correspondence to T.H. (e-mail: thomas{at}hacklaender-online.de).
 |
Abstract
|
|---|
A configurable framework has been developed that can receive, modify, and export images in different picture archiving and communication system scenarios. The framework has three main components: a receiver for Digital Imaging and Communications in Medicine (DICOM) objects, a processing pipeline to apply one or more modifications to these objects, and one or more senders to send the processed objects to predefined addressees. The toolbox programming was implemented as an open source project in Java. The processing pipeline uses the concept of configurable plug-ins. One plug-in is user programmable by means of extensible stylesheet language files and allows conversion of DICOM objects to extensible markup language documents or other file types. Input and output channels are the DICOM Storage service, DICOM compact disks–read-only memory (CD-ROMs), and the local file system. The toolbox has been successfully applied to different clinical scenarios, including the correction of DICOM objects from non–Integrating the Healthcare Enterprise (IHE) conform modalities, pseudonaming of DICOM images, and use of the IHE Portable Data for Imaging profile with import and export of CD-ROMs. The toolbox has proved reliability in the clinical routine. Because of the open programming interfaces, the functionality can easily be adapted to future applications.
© RSNA, 2005
|
Introduction
|
|---|
The exchange of radiologic information is defined by the Digital Imaging and Communications in Medicine (DICOM) standard and the Health Level Seven (HL7) standard (1–5). On the basis of these standards, the Integrating the Healthcare Enterprise (IHE) framework (6,7) defines typical work flows for processes in medical imaging.
When the work flow of a picture archiving and communication system (PACS) is analyzed (Fig 1), the image communication can be divided into three abstract functional domains: In a PACS environment, images acquired with the modalities are transferred between the archive and workstations in a restricted, well-defined world. For the external communication, images can be transferred via the network to another DICOM-compatible system like another PACS (eg, the department server or servers of other enterprises) or another workstation (eg, a teleradiology station). Images leave the PACS as film prints or as image media in the form of DICOM recordable CDs; other PACS have to import images from these media. In all of these scenarios, errors occur due to incorrectly encoded data structures or simply missing interfaces.
View larger version (29K):
[in this window]
[in a new window]
[Download PPT slide]
|
Figure 1. Work flow of a PACS. In a PACS environment, images acquired with the modalities are transferred between the archive and workstations in a closed world. Images typically leave the PACS as film prints or as image media in the form of recordable compact disks (CDs), which also allow standardized image import. As additional functions, the DICOM Router allows import, export, and correction of DICOM objects. DVD = digital video disk, PC = personal computer.
|
|
To allow the communication and the correction of DICOM objects in the work flow, a configurable application has to be connected to an existing channel between two devices. This application should be able to receive images from a DICOM Image Storage Class User or a DICOM recordable CD; it should be able to manipulate the image information and finally export the images to a DICOM Storage Service Class Provider or in the form of DICOM recordable CDs.
The following difficulties can arise from incorrect implementations of the standards: An application (modality, workstation, teleradiology station) can (a) send information into the wrong data fields, (b) send image objects with incorrectly encoded data fields, or (c) send no mandatory information at all.
These difficulties can often be solved by modifying the data elements or deducing their contents from other elements. Manipulation of data elements can also improve use cases that are not defined in IHE. However, this can be time-consuming and fraught with errors when done on an individual case basis.
To achieve the highest possible degree of flexibility, we have developed a processing device in the form of a toolbox of functions that can perform data modifications in an automated fashion while unattended.
|
Materials and Methods
|
|---|
Concept
The concept of our processing software, which we have termed the DICOM Router, is that of a modular structure that allows flexible usage. There are two receivers for incoming DICOM objects: The first receiver can be fed with images from the PACS directly via the network. The router provides the DICOM service Storage as a Service Class Provider. This makes it a receiving node from the PACS point of view. The user can select between two transmission modes: Transport Layer Security (TLS) encrypted transmission or open transmission, both defined in the DICOM standard. The second receiver can access files stored on the file system, either locally on the computer where the toolbox is running or on an external such as a recordable CD. These files must contain DICOM objects and must be stored according to DICOM part 10.
Regardless of which receiver reads a DICOM object, it is decoded into an abstract data structure and enqueued into the processing pipeline of the toolbox. The processing pipeline is implemented as a sequence of plug-ins. Each plug-in represents a self-contained program segment that computes a clearly defined task. It receives a data package from a receiver or from the preceding plug-in, processes the package, and passes it on to the next plug-in of the pipeline.
When all steps of the processing pipeline have been computed, the data package is sent to its addressees. Various senders are available, each realized as a plug-in. This way the toolbox can send data packages consecutively via various output channels to multiple receivers. The current operational version of the DICOM Router provides complementary output channels to the two receivers. In addition, it allows writing of data to storage media organized according to part 12 of the DICOM standard. In particular, these are DICOM recordable CDs.
The software design allows multiple instances of the DICOM Router to run simultaneously on one computer. For each instance, a configuration file defines an inherent processing pipeline including the receiver.
Functional Layer
The functional layer of the DICOM Router is realized as a program library. The usage of this library allows implementation of small programs, so-called front ends, for the different use cases. As one possibility, Figure 2 shows the front end used in the development project with its graphical user interface.
View larger version (54K):
[in this window]
[in a new window]
[Download PPT slide]
|
Figure 2a. Example of a front end. Screens from the DICOM Router show a front end that is organized into three tab cards. (a) On the first card, the user selects and configures the receiver. (b) On the second card, the configuration file is selected. (c) The third card allows one to select the configuration file for the logger and to start the selected receiver. In addition, a progress bar and a text field for the output of the logging information are shown.
|
|
View larger version (47K):
[in this window]
[in a new window]
[Download PPT slide]
|
Figure 2b. Example of a front end. Screens from the DICOM Router show a front end that is organized into three tab cards. (a) On the first card, the user selects and configures the receiver. (b) On the second card, the configuration file is selected. (c) The third card allows one to select the configuration file for the logger and to start the selected receiver. In addition, a progress bar and a text field for the output of the logging information are shown.
|
|
View larger version (46K):
[in this window]
[in a new window]
[Download PPT slide]
|
Figure 2c. Example of a front end. Screens from the DICOM Router show a front end that is organized into three tab cards. (a) On the first card, the user selects and configures the receiver. (b) On the second card, the configuration file is selected. (c) The third card allows one to select the configuration file for the logger and to start the selected receiver. In addition, a progress bar and a text field for the output of the logging information are shown.
|
|
The internal program architecture of the DICOM Router has a multilayered hierarchy (Fig 3). The advantage for the user is that one does not need detailed knowledge of the processes of DICOM communication or of the internal details of the plug-in to adapt functionality. The user just sees the upper program layer of the DICOM Router, composed of the graphical user interface of the selected front end and a configuration file. Figure 4 shows an excerpt from a configuration file for a specific use case, stored in text format. The user can change the values of the attributes of the plug-ins by means of a simple text editor.
View larger version (19K):
[in this window]
[in a new window]
[Download PPT slide]
|
Figure 3. Structure of the DICOM Router shown as a layer diagram. Both the receivers and the plug-ins use the dcm4che library for all DICOM communications. The user defines the desired functionality by modifying a configuration file and controls the DICOM Router with a front end.
|
|
Implementation
The software was programmed entirely in Java (version 1.4) (Sun Microsystems, Santa Clara, Calif). As shown in Figure 3, the DICOM functionality is completely encapsulated in the dcm4che library (8). It also supports the DICOM Secure Transport Connection Profiles for encrypted communication channels. The choice of this library as a lower layer bears the advantage that all higher layers must handle only abstract DICOM structures. This applies to the receivers, all plug-in components, and the program front ends.
Each plug-in is implemented by its own Java class. To allow easy extension with new functionalities, a simple programming interface is defined for the plug-ins. By copying compiled plug-ins to a predefined class folder of the DICOM Router, the plug-ins become available immediately to the processing pipeline without relinking the whole program. The current version of the DICOM Router includes the plug-ins listed in Table 1. The examples described in the introduction can entirely be processed with this set.
More complex functions can be realized through the XSLTransformPlugin. In contrast to the other plug-ins, this one does not have its own processing routine. Its processing function is described and configured by an external text file as an XSL template (9). This concept provides the possibility for the user to program new functionalities that may require complex combinations of elements of the DICOM object. Before the XSL template is applied, the DICOM object is converted into an XML document (10). The conversion enables easy transfer of the DICOM object into other file formats (11), which can be saved to the local file system. For example, one of the XSL templates defined in the project exports DICOM objects as hypertext markup language (HTML) files.
For tracing the program output, the logging library log4j (12) is used. Instead of writing log output to the local screen, this library can also store the log information as local files or send it to any computer attached to the network.
The requirements for the computer hardware are equal to those for the Java runtime environment: A Pentium II processor (Intel, Santa Clara, Calif) with a 400-MHz central processing unit (CPU) and 256-MB memory is sufficient for running the program. The hard disk capacity relates to the performed operations of the plug-ins used. The main program components of the DICOM Router require only 1.5 MB of disk space.
The project has been published as an open source project under the GNU General Public License (GPL) and can be downloaded for free (13).
|
Results
|
|---|
Modification of DICOM Objects
The correct transformation of the data structures, as defined through standards, is a necessary precondition for functional operation processes. However, it is not the case in all of the clinically used systems. The following example illustrates how the framework can be used in practice by simply configuring a plug-in.
Example 1.—
The images that were transmitted from a DSA device into the PACS were displayed completely scrambled (Fig 5a). Analysis of the image data showed that some of the attributes required for image display were incorrect and had to be corrected, as described in Table 2.
Solution.—
The DICOM Router was applied between the modality and the image archive. The DSA device sends the images to the DICOM Router with the DICOM Storage Service Class, whereupon the DICOM Router corrects the incorrect attributes automatically and forwards the image data to the image archive. For correction of the image data, the TagModifyPlugin is used. It is able to replace the incorrect attributes with the correct values. The configuration of the Tag-ModifyPlugin can be gathered from Figure 4. When these image data are called from the image archive by a workstation, the image looks as it does in Figure 5b.
Example 2.—
Anonymization of image data is required in those cases where image data will be accessed outside the diagnostic or treatment area. Teaching sessions and research projects are common examples. In many PACS, this is possible only in a limited way, especially when the data are to be forwarded via CD.
Solution.—
For this process, the image data from the image archive are sent to the DICOM Router by the DICOM Storage Service Class. These image data are then manipulated by the DICOM Router and afterward sent back to the image archive. Here, the PseudonymPlugin, TagModify-Plugin, PrivateRemovePlugin, and UIDModify-Plugin are executed sequentially (Fig 6). The PseudonymPlugin automatically replaces the patient name with a pseudonym, since the field containing the patient name may not be deleted, as it is an elemental part of each DICOM image. The TagModifyPlugin is configured in such a way that a row of fields, which by DICOM standards cannot be deleted, is set with an invalid value. This primarily affects fields like Patient ID and Accession Number. The field Patient ID is maintained as an unambiguous identifier and partly supersedes names of other systems like Order Filler in the IHE context Patient Information Reconciliation. The field Accession Number is partially used for the assignment of findings.
View larger version (16K):
[in this window]
[in a new window]
[Download PPT slide]
|
Figure 6. Configuration of the DICOM Router for removal of patient identification attributes. Images are send from a workstation or modality to the DICOM Router, which clears any personal data from the images. The PseudonymPlugin, TagModifyPlugin, PrivateRemovePlugin, and UIDModifyPlugin are executed sequentially. Afterward, the modified images are stored in the PACS archive as a copy. SCP = Service Class Provider.
|
|
In addition to the DICOM standard defined attributes, there can also be so-called private elements in the DICOM images, whose content is set by the respective creating systems. Since these attributes can also contain the user name (which also occurs in some cases), they are deleted by the PrivateRemovePlugin.
The last plug-in is the UIDModifyPlugin, which sets the SOP [service-object pair] Instance UID, Study Instance UID, and Series Instance UID to another unique value. These must be edited so that the image archive that receives the image data interprets those images as a new examination and deposits them into the image archive. After execution of the plug-ins, a new data set is available in the PACS, which then no longer contains references to the patient.
Example 3.—
Because of the work flow and infrastructure in our hospital, there was a necessity to provide physicians at a remote hospital access to computed tomographic (CT) studies performed in our facility. Since our PACS is equipped with HTML-based image distribution software, the obvious method was to allow the external hospital access to our image distribution system via teleradiology (14). The external physician is connected to a gateway outside the firewall of our hospital via the Internet. The connection requires access certificates and is Secure Socket Layer (SSL) encrypted. To enhance the protection of privacy, the external physician should be able to access only images that have already been pseudonymized.
Solution.—
Images are sent from a workstation to a DICOM Router, which clears any personal data from the images (Fig 6) and fills the data element Referring Physician with a predefined value. Afterward, the modified images are stored in the PACS archive as a copy. By determining special access rights, external physicians are allowed to review only the pseudonamed images with the special value of the data element Referring Physician. For that reason, the DICOM Router is physically located in the server room of the hospital. Logging is configured in such a way that any messages are routed to the computer of the PACS administrator to keep him informed about functionality. Simultaneous processing of multisection CT studies with more than 500 images each runs without any problems. The processing time is directly correlated with the configured processing pipeline, the image size, and the system hardware. A Pentium II system with a processor clock speed of 450 MHz and a processing pipeline of six plug-ins is used in our installation. With a matrix size of 512 x 512 pixels, the processing time of the DICOM Router is 2 seconds per image.
Example 4.—
All images from fluoroscopic examinations should be inverted, as shown in Figure 7.
View larger version (149K):
[in this window]
[in a new window]
[Download PPT slide]
|
Figure 7a. (a) Original fluoroscopic image from a double-contrast enema examination shows the transverse colon. Regions not exposed by x-rays are represented by dark areas. Not until the image is inverted is the usual x-ray pattern shown (b).
|
|
View larger version (152K):
[in this window]
[in a new window]
[Download PPT slide]
|
Figure 7b. (a) Original fluoroscopic image from a double-contrast enema examination shows the transverse colon. Regions not exposed by x-rays are represented by dark areas. Not until the image is inverted is the usual x-ray pattern shown (b).
|
|
Solution.—
Whether a pixel value of 0 should be displayed as black or white is defined by the DICOM element Photometric Interpretation. Therefore, the process of inverting an image can be achieved by changing the value of this element from MONOCHROME1 to MONOCHROME2 or vice versa. Because the modification requires the logical decision as to whether the original value is MONOCHROME1 or MONOCHROME2, the problem could not be solved by the TagModify-Plugin. Rather than programming a specialized plug-in, the XSLTransformPlugin can be adopted. By using the configuration file in Figure 8, the image is converted into the XML representation in Figure 9. After application of the XSL transform in Figure 10, the XML representation is reconverted into DICOM. To speed up the process, the pixel data are not converted to XML.
View larger version (24K):
[in this window]
[in a new window]
[Download PPT slide]
|
Figure 9. Extract from the XML representation of the image in Figure 7. Every DICOM element is represented by an XML element of the type "elm." The fields of the DICOM element, like the tag, are represented by attributes of the XML element. The child XML element "val" covers the value of the DICOM element; this value is actually given in the "data" attribute.
|
|
As a rule-based application, the XSL transformation is done by applying "template" elements to the XML representation as a whole. If more than one template matches the source, the one with the highest priority is chosen. If not specified otherwise, the priority of a template is between – 0.5 and 0.5, depending on the match pattern. In this example, all DICOM elements except the photometric interpretation should be left untouched. For that, the second template in Figure 10 copies all nodes from the source to the destination. As this template has a priority of –2.0, it is overwritten by the first template, which matches only the Photometric Interpretation with a standard priority of 0.5. The new value of the DICOM element is calculated in the "new-photometric-interpretation" XSL variable depending on its initial value.
Communication of DICOM Objects
Besides the exchange of DICOM objects over a network, it is becoming more and more common to use CDs or digital video disks (DVDs) as an off-line distribution medium. To guarantee a reliable interchange of such media, IHE has defined the Portable Data for Imaging (PDI) Integration Profile (6). Two examples of such application of our software are described in this section.
Media Export Example.—
DICOM part 12 (1) defines the media formats of exchange media, especially the format of a DICOM CD. The PDI integration profile expands this definition to a format that includes both the DICOM content and Web content. The Web content is written into a separate directory at the root level and contains extensible HTML (XHTML) (15) files referencing JPEG (Joint Photographic Experts Group) representations of the DICOM images. Through this means, users and patients are able to access the images with a Web browser.
Solution.—
The creation of a PDI conform file structure is realized by the PortableMediaCreatorPlugin. The plug-in itself writes only the XHTML files. For writing the DICOM content and the JPEG files, the plug-in calls the SaveDi-comdirPlugin and ExportImagePlugin. In Figure 11, the resulting file structure is given for one image. The different INDEX.HTM files allow the user to navigate by HTML links through study and series lists up to the image list of a series (Fig 12).
View larger version (21K):
[in this window]
[in a new window]
[Download PPT slide]
|
Figure 11. Directory tree created by the PortableMediaCreatorPlugin. The example shows the tree after the export of one image of a study with the following specifications: The patient is named Hans Mustermann (a pseudonym) and was born on May 22, 1957. The study was performed on December 30, 2004, at 15:31 on a magnetic resonance (MR) imager. The study and series identifiers (IDs) are 4711 and 3, respectively. The instance number of the image is 54.
|
|
Media Import Example.—
A growing number of patients have their previous examinations saved on CDs. To permit comparison of the current and previous examinations, it is desirable to copy images of the previous examination into the PACS.
Solution.—
On an abstract level, IHE describes the import of such CDs by using a Portable Media Importer actor. It reads the DICOM data from the CD media, which should be organized according to DICOM part 12 (1). Besides that, it should perform reconciliation of key attributes. For that, the attributes Patient Name, Patient ID, Patient’s Birth Date, and Patient’s Sex should be replaced by their values in the receiving PACS. Work flow–related identifying attributes, like UIDs, are unchanged, removed, or replaced by the PACS values, depending on the work flow of the importing institution. As the DICOM images are stored with PDI conform on the CD, it contains images from one patient only. As shown in Figure 13, the File Receiver consecutively reads all DICOM files from the file system of the CD and sends them to the processing pipeline. Before the images are sent to the archive, four DICOM elements are modified by the TagModifyPlugin. The new values of the elements are given as properties to the plug-in by means of the configuration file.
View larger version (22K):
[in this window]
[in a new window]
[Download PPT slide]
|
Figure 13. Use of the DICOM Router as an IHE conform Portable Media Importer actor. The DICOM images are stored on a PDI CD. Because one CD contains images from only one patient, the File Receiver consecutively reads all of the DICOM files from the file system of the CD and sends them to the processing pipeline. Before the images are sent to the archive, four DICOM elements are modified by the TagModifyPlugin. The new values of the elements are given as properties to the plug-in. DVD = digital video disk.
|
|
|
Discussion
|
|---|
Software Implementation
A critical part of every DICOM application is its conformity to the DICOM standard, which must be rechecked for each example. To avoid this problem, the application can use a well-tested library for all DICOM accesses. Besides commercial products, some free open source libraries are available for this purpose (16). The DICOM Router uses the dcm4che library, which is free. Compared to other implementations, it is the only one that is implemented in pure Java and has an open development team. It has been tested many times in the IHE context and fulfills 10 of 15 IHE integration profiles (17).
Beyond the low-level DICOM toolboxes, some vendors offer software components that perform specialized functions, like pseudonaming (18) or conversion into various graphic formats (19). Only a few commercial packages enable the user to adapt the functionality to the specific needs (20). An open source approach to that is the DIFAF project (21). It allows the modification of DICOM objects by means of a predefined set of subprograms written in Java. Therefore, the approach of DIFAF is comparable to that of the DICOM Router. The most prominent problem with DIFAF is its use of the OFFIS (Oldenburger Forschungs- und Entwicklungsinstitut für Informatik-Werkzeuge und -Systeme) library for low-level DICOM accesses (22). As this package is implemented in C++, DIFAF has to account for various interfaces between Java and C++. Because of its use of the OFFIS library, the complete application is not binary-compatible with various operating systems, whereas the DICOM Router is. Furthermore, the programming interfaces of the subprograms and the logging mechanism are rudimentarily realized in DIFAF.
The implementation as an open source project and open programming interfaces offer the possibility of solving even other use cases besides those already mentioned.
Modification of DICOM Objects
The design of the framework allows the linear application of processing steps for each image. However, there are some scenarios in which the processing of more than one image is necessary. For example, some viewing stations sort images in the order in which they have been received. This results in an invalid display order. In this scenario, the framework could collect all images and sort them according to the DICOM fields Image Position and Image Orientation. Another scenario is the automated application of multiplanar reformation (MPR) and maximum intensity projection (MIP). For some CT examinations, it makes sense to automatically create a new sequence with a new orientation before the images will be sent to a viewing station. In teleradiology scenarios, it makes sense to reduce the number of images by applying MIP.
The already implemented plug-ins cover a large portion of possible use cases. This is due to the possibility of stringing them together in the desired order and of adapting the individual function by editing a configuration file. One drawback is that it is not possible to change the behavior of the processing queue by logical decisions. Also, it is not possible to modify the contents of a DICOM element with a combination of two or more elements. To get such a result, one has to develop a new plug-in. To avoid this, the XSL-TransformPlugin could be used. Although it does not add any new functionality to the DICOM Router by itself, it enables the user to implement new functions by editing an XSL conform text file. As the XSL processor used by the project allows use of the XPath data model, the user can select and combine XML nodes by using expressions similar to those of traditional programming languages. By this means, even complex calculations are possible.
Confidentiality of Patient Identification in Teleradiology
Teleradiology systems should provide network and software security protocols to protect the confidentiality of patient identification and imaging data, consistent with federal and state legal requirements. There should be measures to safeguard the data and to ensure data integrity by protecting against intentional or unintentional data corruption (23).
In particular, data should be transmitted only via secure channels to the destined addressee (24). In our application, this is realized by use of Secure Socket Layer (SSL) transmission up to the first client of the remote hospital. However, it was not possible to ensure that only authorized users could access this client computer. This fact led to the decision to use a pseudonymization process for all images sent to the remote hospital. With the DICOM Router, this precaution requires just one additional copy process for each examination. The delay of less than 1 minute for a typical CT examination of the head is insignificant in comparison with the entire diagnostic process.
For applications that simply require peer-to-peer connections between two PACS nodes, an interconnection is possible via two DICOM Routers. For this, the connection between the routers is already realized by the Secure Transport Connection Profile implemented by the dcm4che library. If firewalls protect the two PACS, both have to be configured in such a way that a connection between the routers is allowed. This problem can be solved if a DICOM e-mail communication (24) (supplement 54) is used instead of a direct connection (25). However, this is not possible with the existing set of plug-ins. An additional e-mail receiver plug-in and e-mail sender plug-in are required.
Communication of DICOM Objects
The exportation of patient examinations in the IHE PDI format allows the patients and other physicians to view the examinations without the need for specialized hardware and software. Because the CD uses the HTML format, they can view the images on every computer platform they wish to use. In the past, this was often a serious problem, even if DICOM viewer software was included on patient CDs. Another possible application for the PDI CD is to build up a special archive for educational purposes. To protect the privacy of the patients in this case, the plug-ins shown in Figure 6 should be applied before calling the PortableMediaCreatorPlugin.
By using the SaveFilesystemPlugin, the DICOM Router can export DICOM objects to the local file system of the computer where the router is running. This enables other software to process such objects, even if the software is unable to process the DICOM communication.
When images are imported into a PACS, two aspects have to be considered. To ensure the integrity of the PACS, the process of importing external images requires verification of their conformity to the DICOM standard. Within the DICOM Router, the conformity is ensured by the decoding process within the receiver, which checks the image syntax while converting it into an abstract data structure for further processing. In case of decoding errors, images are not enqueued into the processing pipeline. Thus, the PACS is protected against the import of these incorrect images. The second point is to ensure the logical integrity of the PACS. For that, the imported images must be assigned to the correct patient in the PACS. This is realized by implementing a Portable Media Importer actor. However, the current implementation has one drawback: For every CD that should be imported, the configuration file of the DICOM Router has to be modified to reflect the correct patient information. For the future, it is planned to upgrade the front end in such a way that the necessary information could be edited in text fields of the graphical user interface.
|
TAKE-HOME POINTS
|
|---|
DICOM objects can be read and written by means of different techniques and protocols.
DICOM objects can be modified in an automated fashion without the user being present by means of user-defined rules.
An open programming interface allows extension of the functionality.
The toolbox is implemented as an open source project in Java.
|
Acknowledgments
|
|---|
We thank Heinrich Mertens, PhD, for his support and James H. Caldwell, MD, for his critical review.
|
Footnotes
|
|---|
Abbreviations: CD = compact disk, DICOM = Digital Imaging and Communications in Medicine, DSA = digital subtraction angiography, HTML = hypertext markup language, IHE = Integrating the Healthcare Enterprise, PACS = picture archiving and communication system, PDI = Portable Data for Imaging, UID = unique identifier, XML = extensible markup language, XSL = extensible stylesheet language
|
References
|
|---|
- National Electrical Manufacturers Association (NEMA). Standards Publication PS 3, Digital Imaging and Communications in Medicine (DICOM). http://medical.nema.org/dicom/2004.html. Accessed July 5, 2005.
- Horii SC. Primer on computers and information technology. IV. A nontechnical introduction to DICOM. RadioGraphics
1997;17:1297–1309.[Medline]
- Bidgood WD Jr, Horii SC, Prior FW, Van Syckle DE. Understanding and using DICOM, the data interchange standard for biomedical imaging. J Am Med Inform Assoc
1997;4(3):199–212.[Abstract/Free Full Text]
- Health Level Seven, Inc. Health Level Seven (HL7). http://www.hl7.org/Library/standards_non1.htm. Accessed July 5, 2005.
- Dolin RH, Alschuler L, Beebe C, et al. The HL7 clinical document architecture. J Am Med Inform Assoc
2001;8(6):552–569.[Abstract/Free Full Text]
- Integrating the Healthcare Enterprise (IHE). http://www.ihe.net. Accessed July 5, 2005.
- Siegel EL, Channin DS. Integrating the Health-care Enterprise: a primer. I. Introduction. RadioGraphics
2001;21:1339–1341.[Abstract/Free Full Text]
- Zeilinger G. dcm4che: an implementation of DI-COM in Java. Version 1.1.4. http://sourceforge.net/projects/dcm4che/. Accessed July 5, 2005.
- World Wide Web Consortium. Extensible stylesheet language family (XSL). http://www.w3.org/Style/XSL/. Accessed July 5, 2005.
- World Wide Web Consortium. Extensible markup language (XML). http://www.w3.org/XML/. Accessed July 5, 2005.
- Wang C, Kahn CE Jr. Potential use of extensible markup language for radiology reporting: a tutorial. RadioGraphics
2000;20:287–293.[Abstract/Free Full Text]
- The Apache Jakarta Project. Log4j Project. http://jakarta.apache.org/log4j/docs/index.html. Accessed July 5, 2005.
- Hackländer T, Heupel R, Kleber K. Dicom-Router. Version 2.2.10. http://sourceforge.net/projects/dcmrouter/. Accessed July 5, 2005.
- Hackländer T, Kleber K, Schneider H, Demabre N, Cramer BM. Entwicklung einer sicheren und kostengünstigen intrastruktur zum zugriff auf beliebige Web-basierte bildverteilungssysteme. Rofo
2004;176:1167–1174.[Medline]
- World Wide Web Consortium. The extensible hypertext markup language (2Ed): a reformulation of HTML 4 in XML 1.0. http://www.w3.org/TR/xhtml1. Accessed July 5, 2005.
- Radiological Society of North America. DICOM resources on the Internet. http://www.rsna.org/practice/dicom/dicom.html. Accessed July 5, 2005.
- IHE Europe Connectathon results 2005. http://www.ihe-europe.org/con_result. Accessed July 5, 2005.
- NeoLogica. DICOM Anonymizer. http://eng.neologica.it/download/downloadDICOMAnony-mizer.html. Accessed July 5, 2005.
- Crabb A. Free medical imaging software. http://www.idoimaging.com/index.shtml. Accessed July 5, 2005.
- Merge eFilm. MergeCOM-3 Advanced Integrators Toolkit. http://www.merge.com/products/developmenttools/toolkits.asp. Accessed July 5, 2005.
- Hackländer T, Schmidt A, Stöckel A. Web-basi-erte teleradiologie über das Internet: entwicklung eines systems unter besonderer berücksichtigung des datenschutzes [abstract]. Rofo
2000;172: S130.
- Kuratorium OFFIS. DCMTK: DICOM-Toolkit. http://dicom.offis.de/dcmtk.php.en. Accessed February 22, 2005.
- American College of Radiology. ACR technical standard for teleradiology. http://www.acr.org/s_acr/bin.asp?TrackID=&SID=1&DID=12292&CID=541&VID=2&DOC=File.PDF. Accessed July 5, 2005.
- Clunie DA. DICOM Supplements by number. http://www.dclunie.com/dicom-status/status.html#SupplementsByNumber. Accessed February 22, 2005.
- Weisser G, Walz M, Koester C, Dinter D, Duber C. New concepts in teleradiology with Dicom e-mail [in German]. Biomed Tech (Berl)
2002; 47(suppl 1 pt 1):356–359.
This article has been cited by other articles:
|
|
|
|
 
D. S. Mendelson, P. R. G. Bak, E. Menschik, and E. Siegel
Informatics in Radiology: Image Exchange: IHE and the Evolution of Image Sharing
RadioGraphics,
September 4, 2008;
(2008)
287085174.
[Abstract]
[Full Text]
|
|
|
Top
Abstract
Introduction
