International Journal of Medical Informatics (2005) 74, 325—333

The JAVA-based DICOM query interface DicoSE

Michael Prinz∗, Georg Fischer, Ernst Schuster

Department of Medical Computer Sciences, Medical University Vienna,Spitalgasse 23, A-1090 Vienna, Austria

Received 31 October 2003; received in revised form 16 March 2004; accepted 22 March 2004

KEYWORDSDICOM;

Summary DICOM 3 is a very elaborate standard for the communication betweenmedical image devices. It is published in several parts by the National Electrical Man-

JAVA;XML;Web application

ufacturers Association (NEMA). To adequately visualize the data structure definedin parts 3, 5 and 6 of the DICOM standard, we implemented the web based DicomSearch Engine (DicoSE). It allows for querying the DICOM standard data dictionaryfor defined data fields and visualizes the topology of the data which is inherentlypresent in DICOM datasets. For the administration of the underlying data a webbased administration interface is provided. The service is entirely based on freelyavailable software.© 2004 Elsevier Ireland Ltd. All rights reserved.

1. Introduction

The digital imaging and communications inmedicine (DICOM) standard has been developed bythe National Electrical Manufacturers Association(NEMA) and the American College of Radiology(ACR) to enable the communication between medi-cal image handling devices. The multipart standarddefines the data structure of datasets, the messageexchange between devices, the storage of datasetsand the security facilities. For acquiring the stan-dard documents see [1]. For an introduction to thestandard see [2,3]. There is a notable amount ofDICOM implementing applications such as viewers

* Corresponding author. Tel.: +43 1 40400 6655;fax: +43 1 40400 6656.

E-mail addresses: michael.prinz@meduniwien.ac.at,michael.prinz@akh-wien.ac.at (M. Prinz).URL: http://www.mbm.meduniwien.ac.at.

[4], conversion tools [5], programming libraries[6,7], or DICOM servers [8]. For the implementationof a JAVA-based environment for image archivingand image processing called Melange, we decidedto implement a library under the project nameDi-coLib.

Up to now we have developed image process-ing solutions for a single clinical partner at atime, based on various platforms and have installedthe implemented application locally at the clinicalpartner only. To make these applications availableto a bigger auditorium we are developing Melange,a distributed medical image archiving and imageprocessing environment for scientific use in theGeneral Hospital Vienna [9—11]. Based on a com-mercially available image archiving software whichis in selection currently we will provide a portal forsolution oriented medical image processing algo-rithms for all physicians in the hospital area dealingwith medical images. We will continue to develop

1386-5056/$ — see front matter © 2004 Elsevier Ireland Ltd. All rights reserved.

doi:10.1016/j.ijmedinf.2004.03.006

326 M. Prinz et al.

the solutions in tight cooperation with clinical part-ners respectively will migrate the algorithms fromalready existing solutions which have been imple-mented by our department in the past already.

DicoLib allows for reading and interpretingDICOM-datasets. We could not rely on any of theavailable DICOM libraries mainly for two reasons.On the one hand, we had the constraint of im-plementing the library in the programming lan-guage JAVA. Most of the available libraries are ei-ther implemented in C++ or C such as the OFFISDICOM toolkit DCMTK [8], the CTN-software of theMallinckrodt Institute of Radiology [12] or the DI-COM toolkit of the University of California at DavisMedical Center [13]. On the other hand, we neededa library which we can modify if there is the needof implementing additional functionality or of ad-justing it to a specific DICOM device. DicoLib’s func-tionality has been restricted to the visualization ofalready locally available DICOM datasets.

To provide the data defined in the DICOM stan-dard parts 3, 5 and 6 and needed by DicoLib a sub-project called DicoSE has been realized. Part 3 ofthe DICOM standard defines the information objectdefinitions, part 5 the data structure and part 6 the

Fig. 1 The topology of the DICOM data types. The DI-COM elements (DE) represent those data elements whichare actually present in DICOM datasets, e.g. ‘‘patient’saddress’’. They are defined in the DICOM data dictionary(DICOM standard part 6). DEs are united in InformationModule Definitions (IMD), e.g. ‘‘patient identification’’which in turn are united in Normalized Information Ob-ject Definitions (NIOD), e.g.‘‘patient’’, or in InformationEntities (IE). The IEs themselves are united in CompositeInformation Object Definitions (CIOD). The adequate hi-erarchy tree to apply can be identified by the UniqueIdentifier (UID) which should be present in the DICOMdataset. If there is no UID present the modality tag (aDE-element) may be used for finding an adequate CIOD.

[15] and the web interface is provided by theweb-server Tomcat which is included in the JBossdistribution. DicoSE was installed on a PC sup-plied with an AMD XP1700+ Processor, SuSE-Linux8.2 operating system and a 2.4.20 Linux kernel.The PC has been placed in front of the GeneralHospital’s scientific firewall at the Departmentof Medical Computer Sciences (Fig. 2). DicoSE isgenerally accessible via internet at the webad-dress http://www.mbm.meduniwien.ac.at/dicom/dicose.jsp.

2.2. Data structure

The DICOM data types (DE, IMD, IE, NIOD, CIOD,UID, MOD and Macros of DEs) at the applicationserver were implemented as container managedpersistence (CMP) entity beans as defined in theEnterprise JavaBeans (EJB) 2.0 specification [16].Thus, the creation of the database structure, the

datadictionary. DicoLib queries DicoSE for the en-coding and meaning of the DICOM tags of the cur-rently read dataset. Thus, DicoLib is not only ableto identify the DICOM tags (i.e. (0010,0010)) butalso their coding and meaning (i.e. the data ele-ment with tag (0010,0010) contains the patient’sname).

Data fields in DICOM-datasets are specified se-quentially one after another without preserving thetopology defined in part 3 of the DICOM standard(Fig. 1). The topology definitions are also imple-mented in DicoSE and are queried by DicoLib to vi-sualize the dataset’s data adequately.

For the maintenance of the underlying data, forvisualizing and searching the data without using Di-coLib we implemented a generally available webinterface to DicoSE.

2. Materials and methods

2.1. System architecture

DicoSE is entirely based on freely available soft-ware. It is implemented in the programminglanguage JAVA by using Sun’s JAVA 2 PlatformStandard Edition 1.4.2. The underlying data isprovided by the relational database softwareMySQL [14]. The query is done via the Enter-prise JavaBeans (EJB) Application Server JBoss

The JAVA-based DICOM query interface DicoSE 327

Fig. 2 Data transfer chain from the client browser to DicoSE’s database.

storage and loading of the data and the manage-ment of relations between the entities is done bythe application server and does not have to becoded explicitely.

The definitions of the DICOM data types are verysimilar to each other. Each data type contains anID field and a field describing the meaning of theDICOM data type instance. There are some addi-tional fields at DEs (i.e. tag, version, etc.). Thus,it seems obvious to use inheritance for implement-

Fig. 3 The vertical inheritance table struc

ing the entities but the EJB 2.0 specification doesnot allow the inheritance of entity classes amongeach other. There are some workarounds to avoidduplicate columns in the database structure and du-plicate code as described by Proulx [17]. To repre-sent the topology described in Fig. 1 we followedthe vertical inheritance model and defined the ta-bles as described in Fig. 3. The Base table containsmerely the name of all DICOM data types. This isthe direct subtable for all Macros, IMDs, IEs, NIODs

ture following the proposal of Proulx.

328 M. Prinz et al.

and CIODs which are defined in additional tables.The BaseID table expands the Base table by defin-ing an additional ID as it is present at DEs, MODs andUIDs. The Sequence table determines the relationbetween a DICOM data type and its subtype (i.e. IMDand its DEs). The sequence number defined in thesequence table indicates the order of an element’ssubelements.

2.2.1. DatabaseWe started implementing DicoSE by using the objectoriented database software Ozone [18] and laterchanged to the XML-database software Xindice [19].Using an objected oriented database like Ozoneseemed the most efficient approach to store JAVAobjects. Then we decided to base the data trans-fer from the database to the client on XML-streamsalso following the efforts in contributing XML-baseddata structures to the DICOM standard as described[20,21]. It seemed most efficient to use a na-tive XML-database such as Xindice to directly storeand query XML-documents. Furthermore, both thedatabase software products are freely available.Unfortunately both of them are still in a prematurestate and have performance deficiencies compared

e m

2.2.2. Application serverThe service is provided via an EJB applicationserver. We deployed DicoSE to the freely availableJBoss 3.2 server. JBoss is very well maintained byits implementers. There is a very large commu-nity of JBoss users. Thus, it is very likely to re-ceive help during the installation and programmingprocess by reading and posting to the maintainedmailing lists and extensive list archives at the JBosshomepage. To automate the error prone coding ofthe EJB-classes and the EJB-configuration files weused the code generation engine XDoclet [23] incombination with the JAVA-based build tool Ant[24]. XDoclet parses the source code for user-addedattributes and accordingly creates JAVA-code andXML-descriptors.

The access to the defined DICOM entities is man-aged by an EJB session bean (Fig. 4). Thus, the enti-ties do not have to be accessed individually and theclient session is handled by a unique authority. Theentity data derived from the database is transpar-ently converted to EJB entities via the containermanaged persistence mechanism. For transferringthe data to the client, the entities are furtheron converted to XML-data streams. For this con-vuScd(

tb

2Tpwr

anaged by a session bean which transfers the queries to

ersion process, the Castor data binding library issed [25]. Castor includes the command line utilityourceGenerator which creates JAVA classes for theonversion process by interpreting an XML schemaescribing the data structure of the XML-streamFig. 5).DicoLib directly uses the application server in-

erface for querying DicoSE by calling the sessionean methods directly (Fig. 2).

.2.3. Web-servero make the data available to users as simple asossible, we decided to implement a web interfacehich can be used with any web browser. Weefused to use any web technology such as JAVA

to a relational database software like MySQL. Addi-tionally, Xindice has no user authorization handling.Anybody who knows at which port number Xindice islistening is able to query and modify the database’sdata. To avoid intrusions into the database we in-stalled Xindice on a computer on its own and posi-tioned it behind a firewall. Xindice’s deficiencieswere also described at the MIE 2003 Conference[22]. There is no CMP entity support for object ori-ented databases or XML-databases. The databaseaccess has to be coded explicitly via bean managedpersistence (BMP) entity beans which implies addi-tional coding effort and is error prone. Because ofthese deficiencies we finally decided to use MySQLand to cast the stored data to XML-streams.

Fig. 4 The application server logic. Queries to DicoSE arthe corresponding entity classes.

The JAVA-based DICOM query interface DicoSE 329

Fig. 5 Shortened version of the XML-stream of the IMD‘‘Patient Study’’. The base elements of the data typesare defined under the base tag. The DEs are listed underthe sublist tag. The seq tag indicates the order of theDEs.

Applets, Javascript that requires installations orhave to be activated at the client computer. Thedynamic creation of the web pages is done at theserver via JAVA Server Pages (JSP). Any commonwebbrowser, i.e. Netscape, Mozilla, Internet-Explorer, Opera is sufficient. The XML-streamwhich has been created by the application serveris transferred to the web-server. The Tomcat 4.1web-server is included in the JBoss distribution.Thus, no additional web-server software has tobe installed. The XML-stream which is receivedby the web-server is converted to HTML-code viaXSL-transformations (XSLT). XSLT is a language fortransforming XML-documents to various formats,e.g. XML, HTML, text. It is mainly used at web-servers for dynamically converting XML-documentsto HTML-code. Its usage eases the handling ofXML-nodes and XML-data essentially.

2.2.4. ClientThere are two distinct entrance points to theweb interface. The standard user interface allowsfor querying DicoSE only. The administration userinterface is secured by an authorization dialog andadditionally permits the manipulation of the un-derlying data via HTML form elements. The facilityfor the maintenance of the data is necessary sincethe DICOM standard is updated annually by theDICOM committee formed by the American Collegeof Radiology (ACR) and the National ElectricalManufacturers Association (NEMA).

After accessing the DicoSE homepage a menu onthe left-hand side and the DICOM’s object hierar-chy on the right-hand side is presented to the user(Fig. 6). Each DICOM data type can be queried sepa-rately by either clicking at the corresponding menuitem or item in the hierarchy diagram. We have as-signed a characteristic color to each of the DICOMdata types, i.e. DEs are red, IMDs blue, etc. Thecolor scheme is also present in the output of thequery results. After choosing one of the datatypesa search form is displayed on the left-hand side(Fig. 7). According to the chosen data type theuser can select which data type’s element shouldb‘fib

spqbinhtsodttetc

2

Ttcsaa

e used as query value. The elements ‘‘name’’ and‘internal ID’’ are valid for each object. In the texteld underneath, the query value has to be filled iny the user.Underneath the text field there are several

election fields for controlling the query and theresentation of the result, respectively. For textualueries it can be defined if the query value has toe matched exactly, if the value has to be includedn the result only or if case sensitivity is relevant orot. The user may define the depth of the presentedierarchy. A value of ‘‘0’’ results in the presen-ation of the data object’s own elements only, noubelements are presented. By defining a valuef ‘‘1’’ the object and its direct subelements areisplayed. A value of ‘‘99’’ results in the output ofhe whole hierarchy downwards from the elemento all contained DEs. If more than one matchinglement is found the sorting will be done either byhe elements’ internal ID or name by choosing theorresponding value in the search form.

.3. Accessing the data

he query data defined by the user is transferredo the web-server which subsequently calls theorresponding session bean at the EJB server. Theession bean starts a query on all entity objects ofDICOM data type. If one or more DICOM objectsre found, these objects are converted to a single

330 M. Prinz et al.

Fig. 6 The DicoSE homepage. The menu on the left-hand side and the topology on the right-hand side lead to thequery pages.

Fig. 7 DicoSE’s web interface with the query mask for entering the DICOM data to look for. Here the NIOD with name‘‘patient’’ was queried and the whole hierarchy tree is displayed.

The JAVA-based DICOM query interface DicoSE 331

Fig. 8 The edit mode of the administration interface. The field values can be edited, the data object can be deletedor a new one can be created.

XML-stream and passed back to the web-server.The XML-stream is further converted to an HTML-document via XSLT. Finally, the HTML-documentis presented by the client browser. Subelements(e.g. IMDs in NIODs) are displayed in a short versionfor maintaining the list easy to survey, i.e. DEsare presented with their tag and name, IMDs arepresented with their name only. For displaying thesubelement’s detailed version, the user has to clickon the subelement’s name in the short version.

The administration interface provides additionalbuttons for creating, editing and deleting dataobjects (Fig. 8). The access to this interface issecured by a login dialog. After querying anddisplaying a data object in the edit mode, each ofits data fields are modifiable. By pushing the Modifybutton the modified field values are transferred tothe database.

3. Discussion

The implemented DICOM search engine DicoSEeases the interpretation of DICOM data especiallyw

It facilitates the obtaining of a general view of thetopology of DICOM data. To our knowledge, thereis no comparable service available. The administra-tion interface heavily simplifies the maintenance ofthe data in the database which is necessary becauseof the fact that the standard is modified annually.

Currently, DicoSE’s data is based on the stan-dard’s release of the year 2001 but will be soonmodified to conform with the current release ofthe year 2003. To keep track with the annuallypublished versions of the DICOM standard we im-plemented a parser for interpreting the data ele-ments derived from part 6 of the PDF-version ofthe standard. At present the other elements de-fined in the standard have to be adjusted manu-ally. With regard to the longterm maintenance ofDicoSE, we are counting on the XML-version of thestandard which is currently developed by a work-ing group of the DICOM standards committee. Weare already working on the preparations for be-ing able to adjust DicoSE’s data automatically assoon as the XML-version of the standard has beenpublished.

There is a lot of various technologies involved inthis project. We are using HTML and JSP for pre-s

hen there is no powerful DICOM viewer at hand. enting the web interface, XSLT for converting the

332 M. Prinz et al.

XML-data to HTML-code, an EJB-server for providingthe service, XML for the data exchange, a relationaldatabase for the storage of the data and JAVA asgeneral programming language. The usage of thesetechnologies eases the implementation of the ser-vice by utilizing their power in the correspondingfield. For example, there are numerous softwarelibraries for storing data in relational databasesand it is very easy to convert XML data by usingXSLT. The representation of the data as XML-codeheavily simplifies the handling and output of thedata since there are lots of freely available JAVAprogramming libraries at hand (e.g. JDOM, Xerces,Xalan, Castor). On the other hand, the use of sucha large number of technologies makes the main-tenance of the service more difficult, since theknow-how on each of the technologies has to bepreserved.

JAVA poses no performance or stability problemsto the system. On the contrary, the used softwareproducts and software libraries are in a maturestate and are optimized for their operational do-main. JBoss is an accepted and very widely usedapplication server. The same is valid for MySQL as adatabase.

References

[1] National Electrical Manufacturers Association (NEMA), Dig-ital Imaging and Communications in Medicine (DICOM),http://medical.nema.org, 2001.

[2] S.C. Horil, F.W. Prior, W.D. Bidgood, C. Parisot, G. Claeys,DICOM: An Introduction to the Standard, http://www.xray.hmc.psu.edu/physresources/dicom/dicom intro/.

[3] Philips Medical Systems, Dicom Cook Book, ftp://ftp-wjq.philips.com/medical/interoperability/out/DICOMInformation/CookBook.pdf.

[4] University Hospital of Geneva, OSIRIS Imaging Software,http://www.expasy.org/www/UIN/html1/projects/osiris/osiris.html.

[5] David Clunie, Dicom3Tools, http://www.dclunie.com/dicom3tools.html.

[6] Tiani, JDicom Java DICOM Tools, http://www.tiani.com/JDicom.

[7] University Hospital of Geneva, Papyrus Toolkit, http://www.expasy.org/UIN/html1/projects/papyrus/papyrus.html.

[8] OFFIS, DCMTK DICOM Toolkit, http://dicom.offis.de.[9] M. Prinz, G. Fischer, E. Schuster, Austausch, Archivierung

und Verarbeitung medizinischer Bilder mit Melange, Confer-ence of the Osterreichische Wissenschaftliche Gesellschaftfur Telemedizin, a-telmed 2001, Innsbruck, Austria,2001.

[10] M. Prinz, T. Lorang, M. Gengler, E. Schuster, Implementationof a medical database for DICOM datasets, in: Proceedingsof the International Health Information Conference on IN-

[

[

[

[[[

[

[

[

[

[

[

Currently the DICOM standard is available inprinted form or as PDF documents. Thus, the datahad to be transferred manually from the DICOMdocuments to DicoSE’s database. The XML-versionof the standard which is currently developed bythe working group 6 of the DICOM standards com-mittee will ease and promote the developmentof powerful DICOM handling applications in thefuture.

4. Conclusion

We implemented a web based and XML-based nocost search engine for the data structure definedby the DICOM 3 standard. The service isaccessible via the webaddress http://www.mbm.meduniwien.ac.at/dicom/dicose.jsp. The searchengine will be a component of a DICOM interpret-ing library for visualizing DICOM datasets. Theemployed software products are freely available,most of them are published as open source. Thesearch engine is enhanced by an administrationinterface for maintaining the underlying DICOMdata. The data itself is stored in a relationaldatabase. The cooperation between a browser, aweb-server, an EJB-server and a relational databaseseems to represent an efficient way (regarding theimplementation and the maintenance) to complywith the posed requirements.

FOCUS 2000, Vancouver, Canada, 2000.11] M. Prinz, M. Gengler, T. Lorang, E. Schuster, MELANGE:

a Java-based environment for biomedical image archiv-ing and image processing, in: Proceedings of the 14th In-ternational Congress and Exhibition on Computer AssistedRadiology and Surgery, CARS 2000, San Francisco, USA,2000.

12] Mallinckrodt Institute of Radiology (MIR), DICOM CTN-Software, ftp://wuerlim.wustl.edu/pub/dicom/software/ctn/.

13] University of California at Davis Medical Center, DICOMToolkit, ftp://dicom.offis.uni-oldenburg.de/pub/dicom/mirrors/ucdavis/.

14] MySQL, Relational Database, http://www.mysql.com.15] JBoss, EJB-Application Server, http://www.jboss.org.16] Sun Microsystems, Enterprise JavaBeans, http://java.sun.

com/products/ejb/docs.html.17] E. Proulx, EJB Inheritance, O’Reilly OnJava.com, http://

www.onjava.com/pub/a/onjava/2002/09/04/ejbinherit.html.

18] Ozone, Object-Oriented Database, http://www.ozone-db.org.

19] Apache Xindice, XML-Database, http://xml.apache.org/xindice.

20] A. Tirado-Ramos, J. Hu, K.P. Lee, Information objectdefinition-based unified modeling language representationof DICOM structured reporting, J. Am. Med. Inform. Assoc.9 (1) (2002) 63—71.

21] A. Van Nguyen, D.E. Avrin, W.M. Tellis, K.P. Andriole,R.L. Arenson, What Digital imaging and communicationin medicine (DICOM) could look like in common ob-ject request broker (CORBA) and extensible markup lan-guage (XML), J. Digit. Imag. 14 (2 Suppl. 1) (2001) 89—91.

22] M. Prinz, G. Fischer, E. Schuster, DicoSE—–a web-interfacebased on XML for visualizing and searching the topol-

The JAVA-based DICOM query interface DicoSE 333

ogy of the data structure defined by the DICOM 3 stan-dard, in: Proceedings of MIE 2003, St. Malo, France, May4—7, 2003, IOS Press, 2003, ISBN 1-58603-347-6, 292-297.

[23] XDoclet Code Generation Engine, http://xdoclet.sourceforge.net.

[24] The Apache Ant Project, http://ant.apache.org.[25] The Castor Project, http://castor.exolab.org.