Implementing a Multimodality and Multivendor DICOM System: Problems and Solutions
Octavio Barbero, Josep Fernàndez Bayó, Carles Rúbies
Imaging Laboratory, UDIAT-SDI,
Corporació Sanitària Parc Taulí, Sabadell, Spain
Introduction
The wide acceptance of DICOM by all main vendors has led the market to a more and more often situation where multimodality DICOM equipment from different vendors have to communicate to each other. This can be a problematic situation because of the complexity of the DICOM standard itself and because of the different DICOM implementations of each equipment.
We would like to explain our experience in implementing a DICOM multiservice, multimodality and multivendor installation of over 35 nodes. We used free independent tools for solving connectivity problems, and self-developed software (written in C++ and Java) called RAIM for acquiring, viewing and sending DICOM images.
Material and Methods
The radiology facilities of our hospital are spread in four different buildings. The DICOM equipment we have installed is composed of 1 MR, 1 CT, 2 CR, 1 Digital Angiographer, 1 US, 1 DICOM image archive, 4 diagnostic workstations, 5 DICOM printers, and, in a first phase, over 15 PCs with DICOM viewers, which will be progressively incremented to cover most of the hospital, that is between 50 and 100 nodes more. This equipment comes from a 3 different vendors, and our own DICOM development, RAIM, a DICOM viewer in two versions, one developed in C++ and another one in Java.
We have had problems in getting all this varied equipment to communicate using DICOM. After checking all the conformance statements, all the equipment should be able to communicate and configure easily. That has not been our case. The main problems we had can be summarized in the following points:
· The TCP port number of one of the DICOM modalities could only be set between 0 and 32.767, instead of 65.536, which obliged to changed the rest of the DICOM nodes connected to the DICOM archive which had port numbers of 50.000.
· Three of the workstations that were used as DICOM gateways between the modalities and the DICOM archive had problems grouping all images of a single study into one single study (different study UIDs for each image).
· A problem was encountered in the length of the UIDs for syntax negociation. The DICOM standard only specifies that this length does not have to be even for network negociation, so two of the modalities sent odd length UID, and the archive corrected it to even length UID, causing the abortion of operation by the modalities because of a bad recognition of the UIDs returned.
· None of the modalities could send images automatically to a DICOM destination in a correct form (most of them do not even have this option)
· Configuration of DICOM features is very difficult to perform, making the system very unflexible.
· DICOM print and worklist management not supported. Only one of the modalities supported worklist management through a dedicated gateway. Only the printing provider supported DICOM print services.
The digital system was planned to be financed with the saving in films of the emergencies area, where only pathological cases are printed (all of them are digitally archived in a CD-ROM DICOM archive). A saving of 70% was estimated. The real numbers by now, after six months of experience, are a 65% of savings. This is dued mainly to the transition between a traditional method, where everything was printed and the diagnostic made on films, and a digital system where most of the diagnostics are made on computer screens.
We have also had a nice experience using independent and free software, like the DICOM libraries of the Davis Medical Center of the University of California, and their DICOM network analyzer, a tool which is absolutely necessary to be able to understand what is going wrong on a DICOM communication problem. To say more, this software was the only implementation that could ‘talk’ to all other DICOM implementations, except for one.
Conclusion
It is absolutely necessary to proceed through the following steps in order to implement a multivendor and multimodality system:
· Check all the conformance statements from all equipment.
· Ask the vendors if there is a previous installation working with the other planned vendors, where it is and a contact person there. This is the only way to ensure that it will work.
· If the previous possiblity does not exist, then it is highly recommendable to have tools for testing DICOM connectivity problems. There are vendors who have their own tools for testing connectivity of other equipment with their DICOM equipment, and also independent and free tools like the Central Test Node by the Mallinkodt Institute, and OFFIS’ implementation, and the DICOM network ‘sniffer’ and libraries by the Davis Medical Center.
References
1.- Antal Nagy, László Nyúl, Attila Kuba, László Almási. Problems and Solutions: One Year Experience with the SZOTE-PACS. Proceedings of the 15th EuroPACS Annual Meeting, Pisa, September 25-27, 1997.
2.- University of California, Davis Medical Center, http://www.ucdmc.ucdavis.edu/
3.- OFFIS, http://www.offis.uni-oldenburg.de/
Corresponding author:
Octavio Barbero, Josep Fernàndez Bayó, Carles Rúbies
Imaging Laboratory, UDIAT-SDI, Corporació Sanitària Parc Taulí
08208 Sabadell, Spain
e-mail:
labimg(at)siberia.chpt.es
Oral presentation at EuroPACS'98, Barcelona, Spain