A PACS Gateway to the Cloud

A PACS Gateway to the Cloud

Luís A. Bastião Silva, Carlos Costa, Augusto Silva and José Luís Oliveira Departamento de Electrónica, Telecomunicações e Informática da Universidade de Aveiro

IEETA - Institute of Electronics and Telematics Engineering of Aveiro <bastiao, carlos.costa, augusto.silva, jlo>@ua.pt

Abstract— The amount of medical images has increased significantly over the last decade as result of the increase of number and quality of studies. Following some researchers, this trend will continue over the next years. Cloud computing is a new concept based on a well-know model named “pay-as-you-go”. There is a new concept dubbed PACS Cloud, which the fundamental idea is to do PACS outsourcing taking advantages of the clouds elasticity and scalability, avoiding hardware obsolescence, providing universal access to the information anywhere, anytime and increase the data availability. This paper presents a module of PACS Cloud architecture to grant interoperability with DICOM devices. PACS Cloud Gateway is a component of PACS Cloud, which focuses mainly on the translation from DICOM commands to non-DICOM and vice-versa. While data outsource to the cloud can relieve users from the burden of local storage and maintenance, it also brings new security concerns. This paper presents a secure PACS Cloud Gateway to access PACS Cloud archive, which provides a high security level and without cloud’s provider dependence. The workflows of each process was described carefully, specifying data flows since that Gateway is contacted by DICOM device, until it releases the process. Finally, the platform was instantiated in biggest Internet Cloud providers and the solution’s results was analysed.

Medical Imaging, PACS; DICOM; Telemedicine; Cloud Computing

I. INTRODUCTION The amount of medical images has increased significantly

over the last decade [1], it is a natural result of the increase of number and quality of studies that are typically stored in repositories inside the medical institute. Following some researchers [2], this trend will continue over the next years, meaning that PACS (Picture Archive and Communications System) will be dealing with large terabytes or even petabytes of information. Considering that information, those systems need to be scale, and their maintenance costs will increase gradually.

Cloud computing is a new concept based on a well-know model named “pay-as-you-go”. There was a new tendency to use Cloud computing into enterprises and industry, and healthcare market is not an exception. There is a new concept dubbed PACS Cloud, which the key idea is to do PACS outsourcing taking advantages of the clouds elasticity and scalability, avoiding hardware obsolescence, providing universal access to the information anywhere, anytime and increase the data availability. However the concept only itself

does not grant interoperability with DICOM devices. Medical institutions have a huge amount of standard devices that cannot communicate with cloud computing interface directly. This paper presents a module of PACS Cloud architecture to grant interoperability with DICOM devices. PACS Cloud Gateway is a component focuses mainly on translate DICOM commands in non-DICOM requests and vice-versa.

PACS Cloud Gateway makes part of a self-organized PACS system in paradigm “PACS-as-a-service”. Gateway focuses on full compatibly with Digital Imaging and Communications in Medicine (DICOM) standard. It supports two very important services: DICOM Storage and DICOM Query/Retrieve, capable to store, query and retrieve studies to/from repository. Nevertheless there is a vary complexity of physicians to move medical data from on-house datacenter to external providers, claiming lack of privacy and concerning due to patient confidentiality information. PACS Cloud Gateway is aware of this issue, and outlines well defined rules in the PACS Cloud architecture, which provides a high security level, where the privacy of three main entities is respected: hospitals, physicians and patients. The module also offers the possibility to write in multiple storage cloud providers.

II. RELATED WORK The usage of DICOM services within a healthcare

institution is a common activity. The volume of produced data, for instance, by dynamic cardiac modalities (e.g. XA and US), multislice CT, high-field MRI and digital mammography is tremendous and there is an increasing trend to the next years [2]. For instance, CT scans (64/128-slices), PET, MRI with high-resolution have typically more than 100MB. Beyond the huge amount of information, there are a lot of concerns with safety of the data, meaning that losing studies could become a nightmare to PACS administrators, physicians, medical stuff, and obviously for the patient. There is also a new movement to outsource data storage for institutions datacenters outside [3], reducing the maintenance costs within medical institutions, which are not theirs core business.

There is an implementation of medical image file system, [3] which presents a Grid computing model in co-location. The authors claim that the bottleneck occurs typically in PACS server and they propose a distributed file systems in different grids, where the images are split into blocks and the blocks are widespread by different locations. Several strategies have been implemented to avoid flooding on PACS servers. For instance, predictable methods were used to evade overload on the core

servers. The usage of distributes files in different locations and intelligent heuristics has reduced the transfer times. Also, other approach [3] presents a similar scenario based on Cloud Computing. In this case the solution focuses on exchange, storing and sharing Medical images across different hospitals. Apache Hadoop is a distributed file system, which is used by several important companies to distribute theirs contents, e.g. “Yahoo”. The solution uses Hadoop and it can be deployed to a private cloud or, on the other side, installed on a public cloud, even thought in both situations it has a significant difficulty to setup. Besides, it is a scalable solution providing replication. However the paper does not expose any concerns about security issues.

The medical image archive solution in the cloud [1] is a “PACS-as-a-service” solution similar to what PACS Cloud intends to be. The present’s solutions grant interoperability with DICOM devices and its implementation was created in Microsoft Windows Azure. However this solution does not supply any security or privacy method, becoming the proposed solution an easier target to be attacked. Moreover, they do not present any results regarding performance or robustness of presented architecture.

All the discussed solutions are dependent on technology, platform or provider. In contrary, this paper proposes a novel approach that make possible to store medical images in any cloud player and it breaks the barrier between DICOM communications and Web services cloud services, allowing the connection with the PACS Cloud anytime, anywhere, in a secure approach.

III. METHODS AND MATERIALS

A. Cloud Computing There is a new general tendency to outsource compute

power and storage capacity from desktop, portable PCs, and mobile devices to large datacenters[4]. These fashions do not stand for a completely new concept. There are several well-known paradigms that supports outsource as business model, such as mainframes, clustering, grid computing, and the most recent is cloud computing.

Computing devices and Internet access are now available anywhere and anytime, creating new opportunities to share and to use online resources. A tremendous amount of computational power, such as Google and Amazon, and an unaccountable number of Internet resources and services, such as email and storage, are used daily as a normal commodity. Also, Internet bandwidth is abundant, which allows storing data online. So, the major idea is to use Internet cloud, in a self-service model, where the Internet resources are used to rely our services, and these features stand out from the other paradigms, previously referred.

Cloud Computing raises to import business models. Firstly, applications can be delivered as services over the Internet. From end-users side it’s a commodity uses these application like Gmail[5], Dropbox[6], Google Docs[7], and many others. According to cloud computing [8] this kind of software are named as “Software-as-a-service” – SaaS (Fig. 1) Secondly, a lower level in the architecture is “Platform-as-a-service” (PaaS), where developers might create new applications

following the provider’s API (Application Programming Interface) and deploy them (e.g. Amazon S3 [9]). Finally, but not least, there is “Infrastructure-as-a-Service” (IaaS) that supplies resources such as virtualized servers, network devices, and many other resources, e.g. Amazon EC2 [10] is considered a IaaS.

Figure 1. Cloud computing layer

A cloud computing service is a distributed system technology that consists on the aggregation of resources that are distributed into one single system, aiming to virtualize (e.g. decoupling the business service from the infrastructure needed) and scalability (e.g. the capability of the system to grow when it is needed) [11]. Besides, one of the greatest advantages of the cloud computing is about its resiliency. In theory, the cloud computing services are built in such a way that, if a machine fails, the system readjusts itself, in order to avoid the user's knowledge of the machine fail. Taking into account this resiliency, cloud computing seems a useful technology to ensure some level of stability of the network and computational system that a single server cannot provide.

There has been a strong investment in building cloud computing infrastructures for health proposals. For instance, the Harvard Medical School has built an internal computing cloud to enable collaborative research along several departments and partners [12]. Another example, TC3Health Company is already providing health care payers with an integrated solution supported by Amazon Web Services, namely S3, EC2, and SQS technologies [13].

B. PACS Cloud A PACS Cloud solution must grant access to the archive

server anytime and anywhere. The traditional PACS server has two major components: DICOM objects repository and database system. The objects repository typically requests an infrastructure with huge storage capacity to support all DICOM studies. The database module, typically a database management system (DBMS), needs to support the DICOM Information Model (DIM) [14] containing metadata information related to patients, studies, series and images. When an archive receives studies from image modality equipment, it needs to store the images in the file system repository and update the database with elements extracted from the received study. Our approach is based on the outsourcing of these two PACS archive components to the cloud, namely using the new concepts of blobstore and

database accessible through web services. Blobstore are associative memories, e.g. key-value storage providers, where the blob is an unstructured data (value) stored in a container and the lookup is preformed true a text key. They are a key component of most actual cloud platforms and infrastructures, including Google App Engine (GAE) [15], Microsoft Windows Azure[16], Amazon Web Services (AWS) [17] and Eucalyptus [18]. All those players provide scalable and fault tolerant blobstore data management.

The proposed PACS Cloud architecture was thought to separate sensitive data elements manipulation from demanding computational operations. The solution developed is based on 3 components: PACS Cloud Gateway, PACS Cloud Master Index and PACS Cloud Slaves (Fig. 2). This paper focuses on PACS Cloud Gateway, but we are giving a quickly overview of each component towards a better understanding of following chapters.

Figure 2. Architecture of PACS Cloud

The Master Index is the PACS Cloud core entity. It contains information about other modules, including Gateways and Cloud Slaves (repository and database). It also provides authentication services to institutional gateways. Finally, all DIM identifiable information related with patient and study levels are stored in a master index database, fundamental to ensure solutions for confidentiality and privacy.

The Cloud Slaves provide, on one hand, storage of sightless data (objects repositories) and, on other hand, a database containing all no identifiable metadata extracted from DICOM studies, i.e. the most demanding task concerning computational power. The database slaves provide query services over no patient identifiable DIM fields. The proposed architecture makes possible to have one or more Cloud Slave modules hosted in different Internet Cloud providers, e.g. it is possible, for instance, to have a database Slave module and two repository Slaves in three distinct Cloud providers.

Cloud Gateway is a very important component in this architecture (Fig. 2). It provides a interface between DICOM world and Cloud systems. Internet Cloud providers just support web services as system interface, which is a barrier to PACS server implementation through cloud computing. In order to solve this problem was introduced a DICOM-Web service gateway, named PACS Cloud Gateway, that aims to translate DICOM commands in web service request towards a totally connectivity between them, e.g. granting interoperability

between DICOM devices and clouds interfaces. It provides two DICOM services: Storage (e.g. DICOM C-STORE) and Query/Retrieve (e.g. DICOM C-FIND and C-MOVE). Those modules are located in institutional intranet and need to be registered in Master Index to access to PACS Cloud services.

IV. SYSTEM DESIGN AND IMPLEMENTATION

A. Components The PACS Cloud interfaces were specified in a developed

PACS Cloud Framework. As a consequence the PACS Cloud Gateway interfaces was bounded in the framework, too (Fig. 3). The Framework outlines the signaling messages, DICOM messages in XML, API to Master Index, and API to Slaves databases and APIs to Cloud providers. All components of PACS Cloud were implemented in Java, but it can be implemented in another language, since assert the PACS Cloud Framework specifications.

Figure 3. Internal components

PACS Cloud Gateway broke the barrier of non-operability between DICOM devices and Cloud Providers. Therefore it has two different implementations: (1) DICOM server compatible and cloud providers interface (web services). The implementation of DICOM standard is supported by the DCM4CHE library [19], a SDK that is used to extract DICOM data elements from persistent objects, to implement the Storage SCP and Query/Retrieve SCP services (Fig. 4).

Figure 4. Gateway - Components

PACS Cloud Gateway receives DICOM images and it will forward these images to the blobstore in a specified cloud provider. The access to the cloud blobstore providers is supported by jclouds [20] that implement several blobstore cloud providers. Furthermore, the PACS Cloud Gateway sends

Hospital A

Cloud

Modality

Workstations

Trustable provider or on-house

DICOMC-STORE

DICOMC-CFIND

Slave DB BLOBSTORE

Master Index PACS Cloud Core System

GatewayHTTPREST

HTTPREST

!"

!"#$%#&'()%*+,-./'+0%1234.+5,6.%).73242'3%,3)%8'54/,+.%89.6276,42'3:%

!"#$%#&'()%%;,84.+%<3).=%

!"#$%#&'()%%>,4./,?%

!"#$%#&'()%*+,-.+/%0!1'23)-4%56#78%4-1239-4:%;(-1/<=-,13-2-%+>)%$,'1+?-@%

A+2+%B31,(+&%8+9C3>-%

=D$E&-,% F9&'()4% )9GH9C-% !"#$%#&'()%I1+G-.'1J%

metadata information to databases: Master Index and Slaves databases. The communication between the PACS Cloud Gateway and Master Index uses RESTful web services through the RESTlet framework [21].

B. Architecture The PACS Cloud Gateway architecture contains 4 different

packages, such as described below:

• Server DICOM: Contains DICOM Services: Verification, Storage and Query/retrieve. It also encompasses the auxiliary classes to provide interaction with Cloud services.

• Core: It stores all settings and POJO (Plain Old Java Object) classes. It contains a thread mechanism to monitor new requests/signaling from Master Index, but it also holds download manager in order to overcome the download single thread.

• GUI (Graphical User Interface): PACS Cloud Gateway runs graphically on the system tray (platform independent). It contains the system tray graphic stuff and configuration’s window; it is able to add/edit or remove DICOM nodes.

• Clients: In this package are implemented all classes that communicates with Master Index, and Cloud Slaves.

We’ve defined an abstract wrapper to communicate with Master Index dubbed MasterIndex (Fig. 5). It does not supply any implementation, but it holds the interface to the methods implementation, as know as adapter pattern. Thus, the real implementations were done using RESTful client web services through the RESTlet framework, in MasterIndexImpl. Following this principle, the interface can be implemented using another frameworks or other kind of providers, for instance SOAP (Simple Object Access Protocol).

Figure 5. Class diagram (clients package)

One of the biggest concerns in the architecture was the support of multiple providers. In the first stage it looks like a technological problem, but it is not. In order to solve this problem, we have defined a proper classes definition, so that it would become easier to implement it, in other cloud players. Into client package, the class SlaveIndex (Fig.5) is just an adapter to the real implementation, like MasterIndex. We have also created a CloudInputStream and CloudOutputStream to read/write operations in cloud Blobstores providers.

On the server side, there are a couple of classes focusing to create DICOM services listener (Fig. 6). Then forwarding the messages or DICOM objects to the Cloud Slaves blobstores and respective metadata for Slaves databases. It also needs to communicate with gatekeeper, i.e., Master Index, to request other kinds of information like PatientName, study session keys, etc.

Figure 6. Class diagram (DICOM package)

Besides Storage and QueryRetrieve classes, there are also other classes such as FindRSP and CMoveRSP, which are DIMSE responses. These responses were created using the actual state of the PACS Cloud databases. The solution also implements upload and download in multithread towards a better performance on the storage/retrieve medical data. It contains a thread poll to limit the number of threads alive and this value might be changed on gateway configurations.

In order to improve requests handlers to/from slave database, an abstraction to DIM structure was created (Fig. 7), which are maintained in a separated project (PACS Cloud Framework).

Figure 7. Class diagram: DIM model

The initial settings are load from a class named Startup, living in core package. In the first stage it will validate gateway login, and then requests settings, e.g. PACS’s AE Title.

Finally, the gateway, by itself, encompasses configurations. For instance, the TCP ports where DICOM services listen, the username and password, and MasterIndex endpoint. All those configurations can be changed through the GUI or in the config.xml that is created automatically in the first time that application start.

com.pacscloud.gatewayserver.clients

storeMetadata()getStudies()getPatient()getStudy()getSerie()

SlaveIndexstoreMetadata()searchByPatientName()hasCMove()sendCMove()isCMoveDone()

MasterIndex

com.pacscloud.gatewayserver.dicom

doStartService()doStopService()

StoragedoStartService()doStopService()

QueryRetrieve

doStartService()doStopService()getAETitle()getRemoteConn()getDevice()registerServices()

DicomNetwork

-patient namePatient

- study instance uidStudy

- series instance uidSeries

- sop instance uidImages

V. WORKFLOWS AND DATAFLOWS PACS Cloud Gateway is responsible for communication as

DICOM service following DICOM conformance statement and send, query or retrieve information from PACS Cloud in a transparent way to the DICOM client side. On one hand, the movement of images from modality to PACS Cloud happens when acquisition devices send the studies to the PACS Cloud Gateway (Fig. 8).

Figure 8. PASCS Cloud Gateway - generic workflow

A. Storage Service In the storage process, gateway is waiting for DICOM

requests. The DICOM upper layer is maintained by dcm4che2, which deals with association and low-level protocol. Nonetheless, the transfer capability, AEtitles, delays and other important DICOM issues in protocol need to be customized. All those settings are loaded from Master Index.

In the storage workflow, modalities produce images and send images operating with DICOM communications with C-STORE command. Before it happens, modality needs to know which SOP classes and PACS support transfer syntaxes. In step of this procedure, the gateway receives a “DICOM ASSOC REQUEST” to verify if server supports the SOPs. Following the numeration in Fig. 8, in step (1) the acquisition devices invoke a C-STORE command, and data flows to the PACS Cloud Gateway. When the storage process is finished, PACS Cloud Gateway will send the metadata to the slave’s database providers and to the Master Index (steps 2 and 3). Note that all images upload to the Cloud are encrypted with AES algorithm.

B. Query/Retrieve Service The Query/Retrieve process is subdivided in two DICOM

independents commands: C-FIND and C-MOVE, where the C-FIND is associated with the queries and the C-MOVE with image objects retrieve action.

On the other hand, the query and retrieve process are executed from workstations. In the query process there is no communication with blobstore. PACS Cloud gateway just requests information to the indexes (step 5, 6 and 7). The C-FIND request contains query items that can be a sub-set of DIM fields and can contain a wildcard’s elements in search like, for instance, in patient’s name. According with query specificity, it can be executed directly in the DIM Cloud Slave Database (step 6). If the patient’s name is referred in query items or this contains wildcard, there is a query for Master Index. In the end, gateway will collect both data and send C-FIND Response with match’s result.

Likewise, retrieve process execute the same workflow, but it accesses to blobstore to retrieve DICOM objects. In the C-MOVE process, when a C-MOVE Request is received by a gateway, destination AETitle and query level is extracted from the command data. In order to solve moves between multi-institutional sites, a signal is sent to the receiver gateway (step 5 and 6). In the storage process, the download process uses multithread and multiple objects are downloading at the same time. On the other side, gateway starts a DICOM C-STORE process with a negotiation to storage repository. Each object successfully transferred from the blobstore is decrypted with study session key and DICOM C-STORE process sends the object to storage repository. After all objects have been transferred to the local repository association, the C-Move Response is sent to the C-Move requester entity.

VI. RESULTS A new PACS solution, which is able to store medical

studies in the cloud safety, has been developed. The data are in the cloud, but the provider cannot do anything with it because they are all ciphered and the keys live in Master Index, where cloud provider does not access. PACS Cloud Gateway grants interoperability with DICOM devices working as a tradition PACS archive from DICOM client’s side perspective. Furthermore, from the administrator’s side, it reduces drastically the IT infrastructures and brings new management facility in multi-site institutions with shared PACS.

A. Performance measurements The prototype was tested through several study cases with a

huge amount of DICOM images of different modalities, stored in multiple providers: Google Storage and Amazon S3. In all the tests the solution proved to be robust, enable to store, query and retrieve all expected studies.

To evaluate the software in performance and robustness, PACS Cloud was tested several times using a data set of 6 studies containing 855 DICOM files. There are a couple of modalities on those studies: Cardiac XA, US, MR, CT. We have used the campus Internet connection and the gateways are running Pentium4, with a 2,6 GHz processor and 2GB RAM.

We made several trials of storage and retrieve with Amazon S3 and Google Storage, considering just average times of both process. It includes upload and download processes under HTTP and DICOM communication from/to gateway to DICOM devices.

There are average measurements, result of several trials with different modalities. We did the tests with two blobstores providers: Google Storage and Amazon S3 (Table I).

TABLE I. STORAGE MEASUREMENTS

The results were analyzed, and seems that there are

different measures between different providers (Fig. 9), which

ModalityDevices

PACS Cloud Gateway

PACS Cloud Master Index

PACS Cloud Slaves(Cloud

Providers)

PACS Cloud Gateway

(1)

(2)

(3)

(5)

(6)

DICOMC-STORE DICOM

C-FIND/C-MOVE

Workstations

(4)

(7)

(8)

(9)DICOMC-STORE

!"#$%&'( )*+,&%-. /"%01-+!2 3""4%-+5.6 789+9:+5.6!" # $ %&'( )&*)!" $+ ( *&%% ,&#+!" $# '&( ((&$) %,&-(". (#' $)&* %)&#$ (,&$,/01 (%) #-&* *,&*- #,&-)". %-% (+) ((#&), $'$&)'

means that for each provider the solution can be tuned, improving the performance.

Figure 9. Results for Storage process

The download process is faster than upload as can be seen in the results. (Table. II).

TABLE II. RETRIEVE MEASUREMENTS

Likewise in storage process, the retrieve process is faster in

Google Storage than Amazon. However, the last 3 studies are slower in Google Storage (Fig. 10). The tests were performed in a shared connection, and without dedicated link to the Cloud Providers. Thus, the results vary due to Internet latency and noise of ISP (Internet Service Providers).

Figure 10. Results for retrieve process

Besides the security problems, PACS cloud will also solve the problems regarding resizing and the maintenance of datacenter, as well as its reliability, interoperability and performance are beyond expectations. The PACS Cloud Gateway is a fundamental component on this process

VII. CONCLUSION PACS Cloud Gateway is very important to grant

interoperability with DICOM devices, which is very important

for healthcare institutions. The characteristics of the presented PACS Cloud grant a great scalability and reliability of data. It has a significant impact on healthcare institutions, which allows the reduction of datacenter’s IT infrastructure outsourcing the data to the Cloud. In spite of spent energy, air condition, maintenance and other issues, PACS Cloud will work in a financial model “pay-for-what-you-use” having positive environment and financial impact.

The integration inside a healthcare instruction is effortless and inexpensive, given that the solution is compatible with acquisitions and workstations devices. Furthermore, there is no provider dependence in this implementation due to its well-modeling support couple of them, thus being easier to implement new providers. Due to legal issues, namely data protection laws, the approach to outsource the medical data to public data might not be accepted in some countries because they force to know the location where the information is stored. Nevertheless, PACS Cloud Gateway allows storing the medical data in private cloud. Thus, the presented solution is compliant with these laws and possible to deploy in the real environment.

ACKNOWLEDGMENT Luís Ribeiro, Frederico Valente (workmates at IEETA) and

Adrian Cole (from jclouds)

REFERENCES 1. Teng C, Mitchell J, Walker C, Swan A, Davila C, Howard D,

Needham T: A medical image archive solution in the cloud. In: Software Engineering and Service Sciences (ICSESS) - IEEE International Conference Beijing: 431-434.

2. Philbin J, Prior F, Nagy P: Will the Next Generation of PACS Be Sitting on a Cloud? Journal of Digital Imaging:1-5.

3. Yang C, Chen C, Yang M: Implementation of a medical image file accessing system in co-allocation data grids. Future Generation Computer Systems 2010.

4. architecture AOwie: Architectural strategies for Cloud computing. In.; August 2009.

5. Gmail [www.gmail.com] 6. Dropbox Service [www.dropbox.com] 7. Google Docs [http://docs.google.com] 8. Rimal B, Choi E: A Conceptual Approach for Taxonomical

Spectrum of Cloud Computing. In: Ubiquitous Information Technologies & Applications, 2009 ICUT '09 - Proceedings of the 4th International Conference Fukuoka: 1-6.

9. Amazon Simple Storage Service [https://s3.amazonaws.com/ ] 10. Amazon Elastic Compute Cloud [http://aws.amazon.com/ec2/] 11. Steve Bennett MB, Robert Covington: Oracle White Paper in

Enterprise Architecture - Architectural Strategies for Cloud Computing. 2009.

12. RightScale: Center for Biomedical Informatics at Harvard Medical School Minimizes Cloud Computing Management Using RightScale. www.rightscale.com. In.; 2009.

13. Amazon Web Services LLC. 2009. Case Studies: TC3 Health. Web page, http://aws.amazon.com/solutions/case-studies/tc3-health/ In.

14. DICOM-P3: Digital Imaging and Communications in Medicine (DICOM), Part 3: Information Object Definitions. In.: National Electrical Manufacturers Association; 2001.

15. Google App Engine (GAE) [http://code.google.com/appengine/] 16. Corporation M: Windows Azure Platform. In. 17. Amazon Webservices (AWS) [http://aws.amazon.com/] 18. Eucalyptus [www.eucalyptus.com] 19. dcm4che sourceforge project

[http://sourceforge.net/projects/dcm4che/.] 20. jclouds: multi-cloud library [http://code.google.com/p/jclouds/] 21. RESTlet framework [www.restlet.org]

!"!!#

$!"!!#

%!!"!!#

%$!"!!#

&!!"!!#

&$!"!!#

%# &# '"&# %("$# )*"$# &!(#

+,,-./#01,23-/#

450#06#

!"#$%&'( )*+,-./"0/0&%-12"%*+-/!3 4""5%-/617 89:/:;/617!" # $ %&' %&'!" $( ) %&* %&+!" $# +&) $+&+ $,&*"- )#+ $'&. $'&+ $+&$/01 )%' #*&. )(&# ),&#"- %*% )(' *#&, *$&%

!"!#

$!"!#

%!"!#

&!"!#

'!"!#

(!"!#

)!"!#

*!"!#

+!"!#

$# %# +"%# $)"(# '*"(# %!)#

,--./0#12-34.0#

561#1&#