Advanced Querying Architecture for DICOM Systems Rui Agostinho, Manuela Pereira, M´ ario Freire IT - Networks and Multimedia Group, Department of Computer Science, University of Beira Interior, 6201-001 Covilh˜ a, Portugal {ragostinho, mpereira, mario}@di.ubi.pt Abstract Radiology, which deals with medical images for diagno- sis purposes, has seen a lot of improvements during the last decades thanks to information technology. The migration from studies based on physical media to studies based on digital media brought new possibilities and new challenges. One of the most important marks occurred in 1993 with Digital Image Communication in Medicine (DICOM), a standard used to produce, store, display, pro- cess and print medical images. DICOM enabled the development of Picture Archiving and Communication Systems (PACS), complex systems that allow all the major operations needed in medical imaging. In this paper we describe an add-on that brings ad- vanced search possibilities to basic DICOM systems, which usually don’t implement anything similar, since the stan- dard doesn’t require them to. The system we present here is based on a client-server architecture and uses the relational model. 1 Introduction The development of DICOM, the standard that brought uniformity to medical imaging, began in 1983 when the American College of Radiology and the National Electrical Manufacturers Association formed a joint committee. Af- ter 10 years standard’s version 1.0 was voted and passed. Nowadays it’s hard to find a hospital in America, Europe or Asia without DICOM [1]. DICOM was developed based on an object-oriented paradigm where everything (images, studies, reports, pa- tients) are objects with mandatory, optional and conditional attributes. For each object a set of services is available. Ev- ery operation available in a DICOM system must be done using these services. Within the standard, DICOM objects are called Service-Object Pairs (SOP). To avoid identifi- cation problems, each SOP instance has its own universal identifier. Only one data format for DICOM is defined and it is used in image printing, storage and transfer, amongst others. Each DICOM file contains an image and its information and is composed by three elements: header, data set and image. While the header is almost only used to know that the file is a DICOM file, the data set contains text data elements. Each data element has a unique identifier which is also used to order data elements [1]. The image data is placed at the end of the file, after the data set. Each DICOM file contains one single image, but it can be a multi-framed image or even a 3D image. Images can be compressed with lossy or lossless compression using JPEG, JPEG2000, LZW, Run-Length Encoding and others. To archive DICOM files outside a DICOM server a new data type called DICOMDIR was created. It keeps informa- tion about the files and their structure. The system described in this paper extends a stand-alone DICOM server, i.e., a server that isn’t integrated in a PACS. The architecture is composed of a database and two applica- tions. The first application, which runs on a DICOM server, reads DICOM files, processes them and inserts the results into the database. The second application is a client. It runs on physician’s computer, performing queries and displaying the results. 2 Related work With DICOM version 1.0 released in 1993 (and pre- liminary versions released a few years earlier) there are many solutions available today to implement a DICOM based system. From a simple DICOM server to complex PACS that can be integrated with hospital management sys- tems. PACS implementations (available nowadays) may come from main equipment manufacturers [2] - [4], in- dependent software houses [5], [6] and also open source projects [7], [8]. However, there are no tools that only focus on extend- ing stand-alone DICOM server search possibilities. Such