A Multi-Domain Platform For Medical Imaging

Transcription

1 A Multi-Domain Platform For Medical Imaging Carlos Viana-Ferreira, Carlos Costa and José Luís Oliveira DETI/IEETA University of Aveiro Aveiro, Portugal {c.ferreira, carlos.costa, Abstract The increasing adoption of medical imaging equipment in healthcare has been leading to a huge dispersion of data repositories and institutions. Although the quality of diagnostic and treatment is deeply dependent on the health information that is available for physicians, several legal and technological issues have hindered the integration of these data. One of such problems is because traditional medical imaging protocols do not perform well in inter-institutional scenarios. This paper describes a hybrid network platform for medical imaging systems that provides searching and retrieval over multiple centres. Three key components support the system: an indexing engine, a multicast framework and a cloud service. Using a peer-to-peer paradigm with security constraints, the platform gathers the information of medical imaging repositories hosted inside the institutions, allowing physicians to access data when and where they need it. 1. Introduction Medical imaging is a technique and process of acquiring visual representations of tissues and organs, is one of the most important tools in the medical environment and has an increasingly important role in treatment and diagnosis [1, 2]. This tendency follows the growing availability of computational resources, which caused the appearance of new computer-dependent methods of image acquisition (i.e. modalities), e.g. computed tomography and positron emission tomography [3]. Besides the appearance of new modalities, computers are more and more used in the medical environment. The Picture Archiving and Communication System (PACS) concept defines a class of systems that are responsible for digital acquisition, storage, display and distribution of medical imaging data [4]. At the beginning, PACS were developed in an ad-hoc way, most of them formed mainly of modality acquisition equipment, display station and a storage component [5]. With the proliferation of these systems, the need to merge some of them into a major one arose. However, interoperability was restricted to equipment from the same manufacturer. In this context, a normalization effort resulted in the Digital Imaging and Communications in Medicine (DICOM) standard [6]. This standard was well accepted, being implemented in most current medical imaging equipment and much DICOM data has been created and stored in repositories. Most of them have several limitations in interinstitutional search and retrieve operations [7]. However, to exchange imaging data between multiple peers there is no simple solution that does not impose a high level of technical support in institutions. Moreover, the simultaneous exchange of information inside an institution and among peers in different institutions is even more complex. We have developed a new communication system that, using reliable multicast, a cloud computing service and an indexing technology, meets the needs of the medical imaging environment. Reliable multicast is used inside an institution, so peers can communicate in a robust and simplified way. To ease the inter-network deployment process, we have built a relay service that can be hosted in an Internet cloud computing service. The lookup of resources (i.e. DICOM documents) is carried out using the indexing technology. A new protocol stack, including messages and flow control, was also developed. 2. Enabling Standards and Technologies 2.1. PACS PACS is an umbrella term that embraces a set of systems responsible for the visualization, storage, acquisition and distribution of medical imaging. These systems were originally designed to serve a healthcare institution s department. However, it was soon realized that they could be used in a much broader range, connecting departments /13/$31.00 c 2013 IEEE CBMS

2 and even different healthcare institutions. This was the motivation for the development of telemedicine services [8, 9]. In this context, DICOM [6] (version 3) is the standard that defines the main processes of PACS. Among others, DICOM defines the network communication layers, the services commands, the persistent objects coding, the media exchange structure and the documentation that must follow an implementation. It is a well accepted standard in medical information systems, being implemented in most systems of this kind ing Technologies Although DICOM standard allows interoperability among systems from different manufacturers, the existent Query/Retrieve standard service does not allow a contentbased file search. Besides, it does not support searches such as [10]: all CT exams with exposure time over 700. Another problem of DICOM is that, in practice, different institutions do not agree with the assignment of the DI- COM fields. For instance, someone whose name is John Doe Smith may have his exams in one institution as John Smith and in another as John D. Smith. We may say then, that chaos arises when data from different institutions repositories are merged. In this scenario, indexing the DICOM document fields of medical imaging repositories allows the search for any of them, whatever the sharing institution. Besides, searches for patients whose name is John Doe Smith returns not only the resources for patient name John Doe Smith but also data about files stored as belonging to patients named John D. Smith and John Smith to-(p2p) A P2P network is a distributed system where each participant (i.e. peer) shares a part of their own resources. For instance: files, CPU cycles, storage, printers, etc. The service provided by the network is the set of resources that all peers share [11]. The capacity to search for resources in such a distributed system is one of the main challenges of this kind of systems. The technological solution adopted for this challenge has been changing over the time. Firstly, a server containing information about all the resources shared in the network was used. Secondly, queries were flooded within the network, in order to query each peer individually for resources that matched the query. Finally, the current trend to solve this problem is the usage of Distributed Hash Tables (DHT). In the context of medical imaging, with a P2P network, it is possible to develop a system where numerous peers can share with each other their DICOM documents [12] Dicoogle Dicoogle ( is an open source PACS solution developed by our group. It is based on indexing technologies, instead of the traditional relational databases, which allows providing a richer query mechanism that other solutions [7]. Moreover, it has an extensible platform supported by a plugin framework that promotes the development of new features in a simple and modular way. This PACS solution allows not only the access to DI- COM persistent objects locally stored, but it provides also a transparent view of remote repositories that are linked by a P2P network. 3. System Architecture The proposed system architecture follows the P2P paradigm for DICOM documents sharing and it is supported by three data acquisition modules: index, multicast and HTTP/HTTPS. First of all, it is important to mention that the developed system differs in some aspects from a traditional P2P file sharing system. Traditional P2P file sharing systems are designed to grow to hundreds or even thousands of peers with a small amount of files per peer, while a P2P for medical imaging is not expected to have numerous peers, but some of the peers may have thousands or millions of files. By this reason, DHT is not suitable for this scenario, since the cost of rearranging the structure when a peer with millions of DICOM documents joined the network would be unaffordable. Taking into account the specificities of the described scenario, a new solution was adopted whereby each peer is responsible for maintaining an index of its DICOM repository. The main disadvantage of this strategy is concerned with the need of contacting all peers to search. Nevertheless, in this way, it is possible to provide a complex query mechanism and, at the same time, avoiding the network overloading when one peer with numerous DICOM documents joins the network. Figure 1 shows an overview of the network topology. As depicted, each peer is composed of an index and two network interfaces: (Local Area Network) and (Wide Area Network). Inside an institution, the peers communicate using the multicast channel, through the interfaces. In inter-institutional processes, the communications are based on interface via relay service Local Dicoogle is endowed with a local index that maintains a registry of the DICOM documents it is responsible for 90 CBMS 2013

3 Institution A Multicast Channel Relay Service Institution B Figure 1. Diagram of the system architecture. [7]. Unlike traditional PACS archives, based on relational databases, that support only some of the DICOM Information Model (DIM) fields, our approach allow us to index all DICOM metadata. This mechanism is based on Apache Lucene [13], which is a popular search engine API, written in Java, allowing, for example, the creation of an index to support content-based searches [14]. The set-up of this mechanism requires only the definition of the path of the file system in which the DICOM files are or will be. After that, Dicoogle processes each file, using the dcm4che framework [15]. This framework is a collection of applications for healthcare enterprises. This tool is used to get every field of each DICOM document that will then be indexed by Lucene. The management of the index is carried out using Java Native Interface (JNI), in order to monitor the creation, modification or deletion of a file. When one of these events occurs, a routine is called the index update. The search in the local index is carried out using the Lucene API that is invoked in order to search for DICOM documents matching a query. As a result, a description of each file that matches the query is returned. By default, the description of each result has three fields about the file: name, hash and size. However, each DICOM information model field may be requested and also a thumbnail. For file retrieval, with a file name and hash the Lucene API returns the file Messages A message is an elementary piece of information exchanged between peers. The main messages of this system are classified into four types: Query Request, Query Response, File Request and File Response. Query Requests are XML messages generally broadcast, which are used for searching for resources. They contain the query that will be used to ask the local indexes of the receivers of these messages, and also enumeration of the fields that each search result should contain. The figure 2 shows Multicast Channel an example of a query request message. In this example the message has four kinds of parameteres: MessageType This field indicates the kind of the message, i.e. Query, Query Response or File Request. QueryNumber This parameter is present in both query response and query request messages. It is used to match the query response message to its related query request. Query The query parameter contains the query that will be used in the local index to obtain the results that afterwards will populate the query response message. Extrafield As default, a query response has information about the name, size and hash of each DICOM document that match the query. Nevertheless, the system allows the retrieval of more fields in a query response. The extrafield parameters are for the request of additional information about each DICOM document. Figure 2. Example of a Query Request Message. When a peer receives a Query Request, it interrogates its own local index and sends back the results using a Query Response. This response is also a XML message and contains a list of results for the query. The File Request message is an XML message that contains information about the requested DICOM file object, which can contain still images, cine-loops, wave forms, structured reports, etc. If the peer has the requested resource, it sends back a File Response message that includes a binary content of the file requested. These messages are common to both and interfaces Reliable Multicast Communications Inside a healthcare institution, typically, there are a small number of active peers. Consequently, P2P decentralized architecture is a good option for this scenario, due to the following reasons: CBMS

4 The costs arising from a server that maintains a network with only a few peers will be avoided. The stability of the network is an important requirement. It is critical that a network built for the medical environment is available all the time. The P2P decentralized topology is one of the P2P architectures most likely to be stable. Therefore, for the communication inside an institution, it was decided to use a reliable multicast technology based on JGroups [16], an open source solution developed in Java. There are two kinds of entities in this communications module: groups and members. Members can join or leave a group, send messages to all (or individual) members and receive messages from other nodes in the group. Moreover, they are notified when other nodes join or leave the group, and have access to a list of the current members of the group. In order to perform such actions, a process needs to create a channel to establish connection with the group. The messages are exchanged through reliable multicast (or reliable unicast). Therefore, it is guaranteed that each message is always received by its destination and in the same order as they were sent. It is also possible to send messages to a particular node belonging to the members list. To join a group, a peer sends a multicast message with the name of the group it wants to join. If the group already exists, one of the members of the group sends the new peer a list of all active peers. If the group does not exist, the group is created with that single peer. The search begins with a peer (peer A) dispatching a Query Request Message, through multicast, to all other peers of the group. When other peers receive the message, they search in their local indexes using the peer A search criteria. If the local index engine returns a list of results, they are converted into a Query Response Message and sent back to peer A. A will merge all received results in one single list. If peer A wants to retrieve one or more files, it sends a File Request Message to the peer (or peers) holding the resources. The peer receiving this message asks the local index for the file path, reads the file content and sends it back, split in chunks, to peer A using a File Response message HTTPS Communications Through a Relay Service The medical environment is a very special area, since it manages confidential data that must be dealt carefully. The hospital networks are usually firewall protected, allowing communication through only a restricted number of ports and protocols [17]. Besides, peers inside a hospital network are usually not allowed to receive communication from the outside. One of the goals here is to ease system deployment while maintaining system security, avoiding the need for technical support or changes in the computing infrastructure of medical institutions. This led to the decision to develop a Web 2.0 compliant solution that only uses HTTP (Hypertext Transfer Protocol) or HTTPS (HTTP Secure) communication from inside to outside, which is commonly available in institutions. However, one important issue remains: How can two peers in different institutions communicate with each other, if both can only send requests and receive responses? To solve this issue, an Internet third party bridge was developed to support inter-institutional communications transforming requests into responses. This third party works as a relay service that receives messages and forwards them to their destinations. This relay service must be hosted in a place where it is possible to accept sessions initiated somewhere else. Nevertheless, the relay is a central key in communications and that is why it must be stable, resilient and scalable. For this reason, cloud was chosen as the supporting technology of such service. For this bridge, we used Dicoogle Relay service described in [18]. This relay is hosted in a cloud computing service, namely Google App Engine (GAE). In that way, it takes advantage of the automatic scaling, resiliency and geo-distribution of Google s application platform. In short, this relay receives the messages of the peers and stores them. In the meantime, all peers are constantly checking if there are new messages destined to them. The system messages are encapsulated in HTTP or HTTPS messages, accordingly to previous configurations of the service. The HTTP message header is also used to transmit some important data to forward medical imaging message, such as the name of the peer and the message purpose. To assure data privacy, the system uses HTTPS between peers and GAE and Advanced Encryption Standard (AES) ciphering with keys of 256 bits for communications between peers. To be able to make inter-institutional communications, there are two possible ways: (1) using an already running relay service, or (2) installing a new relay service instance. In the first case, it is only necessary to know the address of the running relay service and register the new user. When the relay administrator validates the registration, an is sent to the new user with the farm ID. This farm ID is a key used to assure communications privacy, through Advanced Encryption Standard (AES) ciphering. In the second case, using the relay web interface, it is possible to create a new service instance. After that, the user becomes the administrator of the service and is able to advertise the address of the service through the channels 92 CBMS 2013

5 found to be most convenient. To join the network, the user must provide the username and password to the client application, i.e. the Dicoogle. These parameters are used to login in the relay service. After the login is carried out, the Dicoogle instance is able to receive and send messages to the community. A client keepalive message is sent, at intervals of 30 seconds, to inform relay service that the peer is still active. The search and retrieval of DICOM documents is similar to the intra-institutional process, described above and uses the messages described in 3.2. The main difference lies in the third-party relay that intermediates communications. Thus, the message flow is the same as the one described for the intra-institutional communications, but between the origin and the destination, the messages passes through the relay service where they are temporarily stored until the destination asks for new messages. 4. Results The developed medical imaging network is a hybrid network, because it is decentralized inside an institution and centralized in a service for inter-institutional communications. To prove the validity of the solution, it has undergone some tests. Figure 3 shows the length of time from the application sending the search request until retrieval of results, in seven different scenarios: (1) Only the local index is consulted (Local); (2) There are two peers in the Local network, i.e. the peer that queries and the peer that answers ( 2 s); (3) With 3 peers in, i.e. the peer that queries and two peers answering ( 3 s); (4) With 4 peers in, in other words, one peer receiving the results and three answering ( 4 s); (5) Two peers in ( 2 s); (6) Three peers in ( 3 s); (7) With four peers connected by GAE, i.e. one receives the results and 3 others answer ( 4 s). Figure 3. Graph of the time the network takes to retrieve search results in different situations. For each of those scenarios, numerous queries were sent, in order to assess the behavior of the network under different distributions and numbers of peers. The peer, in which the local evaluation was carried out, is endowed with an Intel Core Duo E8400 processor and 4 GB of memory. The other 3 machines used during the tests were similar or slightly worse than this one. The local area network used had a bandwidth of 100 megabits per second, with several machines generating some daily traffic. For what concerns to the tests, the bandwidth of Internet access from inside of an institution depends on numerous factors, for instance, the traffic generated by the users in a specific instant. Thus, the tests were done to assess the average Internet access bandwidth of a hospital in Aveiro region, the results pointed to 17 megabits per second. For that reason, in the tests of the system, the peers had an Internet access bandwidth of 17 megabits per second of upstream and downstream. It is worth noticing that in every search, all possible results were retrieved. From analysis of figure 3 it is possible to conclude that, as expected, the fastest search is the one performed over local index and the slowest one is the search in, mainly due to the normal inter-institutional communication latency. Another conclusion that may be taken is related to the number of peers: the larger number of active peers the better is the network performance, due to the increasing computational power of the peers. In fact, from about results, the collaboration of 4 peers (3 of them sending the results) the solution is faster than the one with 2 peers in (1 sending and 1 receiving results). This may indicate that despite the traffic passes through a relay service, the performance is not critically affected, once the bottleneck seems to be not only the network conditions but also the processing power of the peers sending the messages. In fact, the topology of the peer-to-peer network for medical imaging is a hybrid one. On the one hand, the is fully decentralized, where each peer communicates with all the others from equal to equal. The queries are flooded in the network in such a way that all peers are guaranteed to receive the message, ensuring that when a search is made, all results are retrieved. On the other hand, the is centralized in a cloud relay service, where all messages pass through an intermediary (Google App Engine), to promote communication among all peers, even if they are behind firewalls or routers. Therefore, the developed network is a P2P decentralized in and centralized in a relay service in. The relay service provided in the cloud through a HTTP/HTTPS interface, allows other kind of scenarios such as the Dicoogle Mobile [19], an application developed for Android mobile devices. This application communicates with the relay service as a normal instance of Dicoogle, being able to search and to display the medical im- CBMS

6 ages that are retrieved from the network, taking advantage of the increasingly screen resolution of mobile devices. The application has also a cache with the most recently used images to minimize the effect of the communication latency. 5. Conclusions One of the most important advantages of digital imaging systems is to allow the widespread sharing and remote access to imaging studies and associated data. This paper presents a medical imaging network with a -to- architecture. A set of service messages was defined according to medical imaging scenario requirements. The interinstitutional messages exchange is supported by a reliable and scalable Cloud-based relay service. The hybrid topology of the network allows the search and retrieval of DI- COM objects in three levels: locally, inside an institution and in other institutions. The system promotes cooperation between medical institutions in order to improve the healthcare service. Also, it is an off-the-shelf solution, being very easy to install. Besides, there is no need to configure routers or firewalls, or set up VPN connections, being one potential alternative to the solutions currently used. Another advantage is related to the index that allows more complex queries than a traditional PACS. This solution can be used not only to implement repository federation, but also to exploit telemedicine and telework platforms. 6. Acknowledgments This work has received funding from Fundação para a Ciência e Tecnologia (FCT) under grant agreement PTDC/EIA-EIA/104428/2008. Carlos Viana-Ferreira is funded by the FCT grant SFRH/BD/68280/2010. References [1] M. J. McAuliffe, F. M. Lalonde, D. McGarry, W. Gandler, K. Csaky, and B. L. Trus, Medical image processing, analysis and visualization in clinical research, in Proceedings of the 14th IEEE Symposium on Computer-Based Medical Systems, (Bethesda), pp , IEEE, [2] H. Pohjonen, P. Ross, J. G. Blickman, and R. Kamman, Pervasive access to images and data-the use of computing grids and mobile/wireless devices across healthcare enterprises, Information Technology in Biomedicine, IEEE Transactions on, vol. 11, pp , [3] R. Acharya, R. Wasserman, J. Stevens, and C. Hinojosa, Biomedical imaging modalities: a tutorial, Computerized Medical Imaging and Graphics, vol. 19, pp. 3 25, [4] R. H. Choplin, J. M. Boehme, and C. D. Maynard, Picture archiving and communication systems: an overview, Radiographics, vol. 12, pp , [5] H. Huang, PACS and imaging informatics: basic principles and applications. Wiley-Blackwell, [6] ACR-NEMA, Digital Imaging and Communications in Medicine (DICOM). Rosslyn, VA: National Electrical Manufacturers Association, [7] C. Costa, F. Freitas, M. Pereira, A. Silva, and J. L. Oliveira, ing and retrieving dicom data in disperse and unstructured archives, International Journal of Computer Assisted Radiology and Surgery, vol. 4, pp , [8] D. A. Perednia and A. Allen, Telemedicine technology and clinical applications, JAMA, vol. 273, pp , [9] F. Mair and P. Whitten, Systematic review of studies of patient satisfaction with telemedicine, BMJ, vol. 320, pp , [10] M. Santos, L. Bastio, C. Costa, A. Silva, and N. Rocha, ENTERprise Information Systems, vol. 221 of Communications in Computer and Information Science, ch. DICOM and Clinical Data Mining in a Small Hospital PACS: A Pilot Study, pp Springer Berlin Heidelberg, [11] R. Schollmeier, A definition of peer-to-peer networking for the classification of peer-to-peer architectures and applications, in Proceedings of the First International Conference on -to- Computing, pp , [12] C. Costa, C. Ferreira, L. Bastião, L. Ribeiro, A. Silva, and J. L. Oliveira, Dicoogle - an open source peer-to-peer pacs, Journal of Digital Imaging, vol. 24, pp , [13] A. Jakarta, Apache lucene-a high-performance, full-featured text search engine library, [14] U. Schindler, B. Bruer, and M. Diepenbroek, Data information service based on open archives initiative protocols and apache lucene, in German e-science Conference, [15] G. Zeilinger, O. Montgomery, D. Evans, F. Willer, S. Viswanathan, and T. Bowles, The dcm4che project homepage. Technical report, dcm4che.org, [16] B. Ban, Jgroups, a toolkit for reliable multicast communication, [17] F. Valente, C. Viana-Ferreira, C. Costa, and J. L. Oliveira, A restful image gateway for multiple medical image repositories, Information Technology in Biomedicine, IEEE Transactions on, vol. 16, pp , may [18] C. Viana-Ferreira, C. Costa, and J. L. Oliveira, Dicoogle relay - a cloud communications bridge for medical imaging, in Proceedings of the 25th International SymposiumComputer-Based Medical Systems (CBMS), (Rome, Italy), pp. 1 6, June [19] C. Viana-Ferreira, D. Ferreira, F. Valente, E. Monteiro, C. Costa, and J. L. Oliveira, Dicoogle mobile: a medical imaging platform for android, Studies in health technology and informatics, vol. 180, p. 502, CBMS 2013