Object-Oriented Implementation of a DICOM Network ...

1 downloads 0 Views 154KB Size Report
Most of the digital medical devices used in modern clinics and practice provide data corresponding to the DICOM Standard 2 . Cyclops 1 , a knowledge-based ...
Object-Oriented Implementation of a DICOM Network Client in Smalltalk Dirk Krechel, Kerstin Faber AG Knowledge Based Systems, FB Informatik, University of Kaiserslautern, Germany Aldo von Wangenheim, Silvio Costa Sampario Dep. of Computer Science, Federal University of Santa Catarina, Brazil 1

Objectives

Most of the digital medical devices used in modern clinics and practice provide data corresponding to the DICOM Standard [2]. Cyclops [1], a knowledge-based image analysis system developed at the University of Kaiserslautern, was suitable to analyze such images, but we needed a DICOM interface to connect to DICOM databases easily and transfer data to the system. All non-commercial software available were not be up to our demands, so we implemented a DICOM Network Client by our own, which can connect to the ctn image server [3], basing on a SQL database. We attached great value to a neat, object{oriented implementation, because it is easy to expand and we are exible to future versions of the DICOM Standard. 2

Methods

2.1 Information Model DICOM 3.0 relies on explicit and detailed models of how Real-World objects (patients, images, etc.), involved in radiology operations, are described and how they are related. These models allow manufactures and users to understand the basics structures used in DICOM and clearly show both the data items required in DICOM model and how these items interact. The DICOM Information Model is described in Part 3 of the DICOM Standard. It bases on an Entity-Relationship-Model [4] to model the Real-World. The Entities are Real-World objects like a Patient, a Study or an Image, which are described in Information Object De nitions (IODs). IODs can be composite or normalized. Normalized IODs represent simple Real-World objects and consist only of one single Information Entity (e.g. Patient, Study). Complex Real-World objects like a CT1 Image or an MR2 Image, are represented by Composite IODs, which contain several Information Entities. 1 2

Computer Tomography Magnetic Resonance

1

Object

CyclopsPatientDB

CyclopsDBObject

CyclopsPatient

CyclopsPatient Module

CyclopsCT ImageModule

CyclopsStudy

CyclopsMR ImageModule

CyclopsGeneral StudyModule

CyclopsSC EquipmentModule

CyclopsPatient StudyModule

CyclopsGeneral ImageModule

CyclopsImage PlaneModule

CyclopsSeries

CyclopsGeneral SeriesModule

CyclopsContrast BolusModule

CyclopsImage PixelModule

CyclopsDicom CTImage

CyclopsOverlay PlaneModule

CyclopsDicom Image

CyclopsDicom MRImage

CyclopsUS ImageModule

CyclopsDicom SCImage

CyclopsXRAY ImageModule

CyclopsSOP CommonModule

CyclopsDicom USImage

CyclopsDicom XRAYImage

Figure 1. Class Hierarchy of the IODs

The relevant IODs of DICOM for our applications are CT, MR, Ultrasound and X-Ray images, which are described in Composite IODs. Figure 1 shows the Class Hierarchy of our implementation. Patient, Study and Series objects are subclasses of CyclopsDBObject, whereas all image classes are subclasses of a generic DICOM image class.

2.2 Service Classes The DICOM Standard de nes a set of generic operations (store, get, nd, move, etc.), which can be applied on an object (like a CT image), and calls them the DICOM message service elements (DIMSE). The services provided by DIMSE can be di erentiated in DIMSE-C (related to Composite IODs) and DIMSE-N (related to Normalized IODs) Services. The information description (DICOM object) and the operation to be applied on this object (service) are combined in a class called Service Object Pair Class or SOP Class. The SOP Classes represent the elemental unit of functionality de ned by DICOM. A device may, for a particular SOP Class, perform one of two roles: in the service class provider (SCP) role, it acts as a server for the and in the service class user (SCU) role, it is a client. 2

We implemented the SCU role. For the communication with the image server we needed the standard Query/Retrieve Service Classes, mainly C-STORE and C-FIND, C-GET for every Information Entity and Module.  The C-STORE service is invoked by our application to request the storage of Composite SOP Instance information by the DICOM Image Server.  The C-FIND service is invoked by our application to match a series of attribute strings against the attributes of the set of SOP Instances managed by the DICOM Image Server. The C-FIND service returns a list of requested attributes and their values for each match.  The C-GET service is invoked by our application to fetch the information for one or more Composite SOP Instances from the DICOM Image Server, based upon the attributes supplied by our DICOM Image Server. The result of these services invoke the SCP to send a stream, including images and the related information. Table 1 shows the modeled Service Object Pair (SOP) Classes. SOP Class Name Modality SOP Class UID CT Image Storage MR Image Storage Ultrasound Image Storage X-Ray Image Storage Patient Root Query/Retrieve Information Model - FIND Patient Root Query/Retrieve Information Model - GET Study Root Query/Retrieve Information Model - FIND Study Root Query/Retrieve Information Model - GET

CT MR US X-Ray

1.2.840.10008.5.1.4.1.1.2 1.2.840.10008.5.1.4.1.1.4 1.2.840.10008.5.1.4.1.1.6.1 1.2.840.10008.5.1.4.1.1.12.1

{

1.2.840.10008.5.1.4.1.2.1.1

{

1.2.840.10008.5.1.4.1.2.1.3

{

1.2.840.10008.5.1.4.1.2.2.1

{

1.2.840.10008.5.1.4.1.2.2.3

Table 1. Implemented SOP Classes

2.3 Graphical User Interfaces In cooperation with our medical partners we designed special graphical user interfaces, which do justice to the structure of the DICOM objects. 2.3.1 Dicom Editor The Dicom Editor Figure 2 gives access to all patients stored in the database. After selecting a special patient the Editor enumerates all taken studies. In the same way, all series belonging to a chosen study are displayed. The Notebook on the right side shows all patient, study and series attributes. It is possible to change them and store these changes in the database. At the bottom, the series' images are distributed as thumbnails, so that the user can check, whether he has loaded the correct series. 3

Figure 2. Dicom Editor

2.3.2 Dicom Series Editor

The Dicom Series Editor Figure 3 distributes all images of a series on screen as on a light canvas, but more comfortable.

Figure 3. Dicom Series Editor

4

For example, it gives the possibility to change the images sizes and mark special regions with a red pen without destroying the original image. This is realized with the overlay-concept described in the DICOM-Standard. Another feature is to demand the color value or the average color value of the ROI3. In case of a contrast series the images are distributed in a speci c way so that they can easily be interpreted by radiologist: The images belonging to one volume are placed in the same column and all images, which show the same region, are placed in one row. To analyze such series, it is important to observe the change of signal intensity during time, which is displayed by a histogram Figure 4.

Figure 4. Dicom Histogram

2.3.3 Dicom Image Editor

After selecting a special image in the Dicom Series Editor one can open the Dicom Image Editor Figure 5 with this image. It presents the image and o ers functions to change and store all image-speci c attributes. The DICOM attributes are presented in the Notebook on the left side of the editor. Every page of it represents one of the IOMs4 for the presented Image. The image itself can be manipulated by using several image processing operators e.g. the window levels. egion Of Interest nformation Object Modules

3 R 4

I

5

Figure 5. Dicom ImageEditor

3

Conclusion and Future Work

Now the Cyclops system can easily be connected to a number of medical imaging equipment's. The DICOM Client is a rst step to Intranet solution. In future the Smalltalk System will act as a WWW-Server and all data can be viewed and analyzed in simple browsers. The basic Worklist Management and the structured reporting supplements will be the next extensions. Our DICOM implementation should provide an integrated System for the clinical praxis of our medical partners in Germany and Brazil. References

[1] A. von Wangenheim, Cyclops { Ein Modell zur wissensbasierten Bildinterpretation am Beispiel von Kernspintomographien. Dissertation, University of Kaiserslautern (1996). [2] ACR/NEMA Standard, Digital Imaging and Communications in Medicine (DICOM). [3] http://dicomctn.wustl.edu/DICOM/ctn.html. [4] P. Chen, The Entity-Relationship Approach to Logical Data Base Design

6

Suggest Documents