Dicoogle is a new approach regarding medical image file sharing when compared to the previous Dicoogle desktop version [12
]. This new version supports both P2P and client/server usage, and provides a lightweight communication platform based on P2P technology. This PACS is appropriate for small or medium-sized institutions and it can be used in regular clinical workflow, research, or teaching. On other hand, Dicoogle has a search mechanism that can be used in existent repositories to assist in knowledge extraction, a fundamental tool for clinical studies. It can also be installed in parallel with actual institutions PACS, indexing all existent imagiologic information.
With this approach, distinct medical imaging repositories can be viewed as federated PACS. Interoperability with other DICOM-based systems is provided by standard Storage and Query/Retrieve SCP services. Studies can be searched and retrieved from any of the network peers, according to pre-defined access control policies.
Dicoogle conveys several key features regarding new ways of looking into meta-imaging information for retrospective assessments. These may be of relevant usefulness in statistical-oriented management and reporting tasks or wide-scope clinical studies requiring, for example, dose metrics that are now increasingly available in DICOM persistent objects created by the recent models of digital image equipment.
As long as the storage of DICOM files prevails in file-system-oriented archives, our system is able to provide a way to ensure a vendor-independent DIM structure of the whole archive regardless of the particular implementation of the PACS database. This adds up to any particular redundancy policy eventually deployed by the PACS vendor and easily copes with technological migrations whenever and for whatever the motives that may drive the need for deep changes.
Modules and Interface
Dicoogle was developed in Java as an open source platform that can run in distinct operation systems. The engine can be installed as an operating system service since the presentation layer (i.e., the graphical interface) is decoupled from business logic layer (engine).
All Dicoogle functionalities, operational configurations, and security policies can be configured by the user, including:
- DICOM services ports and allowed host connections;
- Index server file location and basic index operations;
- Configuration of index fields: DIM only, all attributes from specific image modality (XA, US, CT, etc.), and all detected textual attributes;
- P2P configurations.
As described, Dicoogle indexing scheme allows searching through traditional DICOM information fields and in any other indexed attribute. For every medical imaging modality, the administrator can define the desired indexed mode: DIM fields, selected fields, and full index. In the user interface, the list of all indexed fields of a specific image is available to help the user formulate each query (Fig. ).
Display list of indexed fields
In the search interface (Fig. ), besides the usual PACS searching features, a free text mode is available allowing users to construct interactively their own query. For instance, it is possible to specify each field, boolean operators to refine the query (Modality:CT and ExposureTime:>700), nearby terms (PatientName:“Robert Laurent” ~10), and flexible range (StudyDate:[20030801 TO 20040201]). The query results are displayed in a tree-view following the traditional DIM model: patients, studies, series, and image.
Search window in P2P mode
When Dicoogle is connected in the P2P network, the search can be executed in all peers. If the user wants to retrieve medical imaging data stored in remote peers, the download manager module will provide feedback about operation progress, thus increasing Dicoogle usability in P2P mode. When a download finishes, the image can be opened and manipulated locally.
In order to evaluate Dicoogle performance in peer-to-peer scenarios, we have used a regular operational 100 Mb LAN and four common desktop computers with distinct computational resources to build a heterogeneous PACS group. The slowest computer was a Pentium4, with a 2.6-GHz processor and 512 MB RAM, while the fastest was an Intel Core Duo E8400, with 3.0-GHz CPUs and 4 GB of memory. In each of these peers, 40,000 DICOM files were indexed for the trial.
To measure Dicoogle response times, we generated successive sets of queries whose responses return an increasing number of results (patients and images), between zero and 41,000. These queries were repeated from one single peer up to the four peers. It must be mentioned that the queries over a single peer were performed locally, using Dicoogle desktop mode. In this way, the results not only allow us to evaluate the scalability of the P2P solution but also the performance of the distributed operation mode against the local one.
A total of 3,000 queries were generated, and for each sub-set the mean was calculated. The final results are shown in Figure . The purpose of each experiment was to compare search times and to establish a relationship between the number of results found and the time needed to get results through a query among peers.
Dicoogle query response times
These results show that Dicoogle can be used effectively to search studies in a P2P network. For a query result associated, for instance, with a list of 1,600 images, this represents in our repository a response time that varies between 136 ms (one fast peer) and 750 ms (two peers). In P2P group search, the impact of the querying processing distribution may reduce even more this response time (Fig. ). In this case, the P2P threshold will be the network bandwidth.