See

discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/235752104

A PACS gateway to the cloud

Conference Paper January 2011

CITATIONS READS

8 403

4 authors:

Lus A. Bastio Silva Carlos Costa

BMD software University of Aveiro
41 PUBLICATIONS 212 CITATIONS 115 PUBLICATIONS 431 CITATIONS

SEE PROFILE SEE PROFILE

Augusto Silva Jos Lus Oliveira

University of Aveiro University of Aveiro
122 PUBLICATIONS 618 CITATIONS 190 PUBLICATIONS 761 CITATIONS

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Image Analysis and Machine Learning Platform for Innovation in Diabetic Retinopathy Screening View
project

MedBioinformatics - Creating medically-driven integrative bioinformatics applications focused on

oncology, CNS disorders and their comorbidities View project

All content following this page was uploaded by Lus A. Bastio Silva on 27 February 2014.

The user has requested enhancement of the downloaded file.

 A PACS Gateway to the Cloud
Lus A. Bastio Silva, Carlos Costa, Augusto Silva and Jos Lus Oliveira
Departamento de Electrnica, Telecomunicaes e Informtica 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 clouds 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
solutions 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 presents 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 its 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 providers 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.
Master Index
PACS Cloud Core System
Hospital A
Modality
HTTP Trustable provider or on-house
REST
DICOM
C-STORE
DICOM
Workstations C-CFIND
Gateway
HTTP
REST
Slave DB
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.
!"#$%#&'()%% !"#$%#&'()%%
>,4./,?% ;,84.+%<3).=%
!"#$%#&'()%*+,-./'+0%
Cloud
1234.+5,6.%).73242'3%,3)%8'54/,+.%89.6276,42'3:%
!"
Figure 3. Internal components
BLOBSTORE
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).
!"#$%#&'()%*+,-.+/%
0!1'23)-4%56#78%4-1239-4:%;(-1/<=-,13-2-%+>)%$,'1+?-@%
!"#$%#&'()%
=D$E&-,% F9&'()4% )9GH9C-%
I1+G-.'1J%
A+2+%B31,(+&%8+9C3>-%
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
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 configurations 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.
Weve 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).
com.pacscloud.gateway
server.clients
SlaveIndex MasterIndex
storeMetadata() storeMetadata()
getStudies() searchByPatientName()
getPatient() hasCMove()
getStudy() sendCMove()
getSerie() isCMoveDone()
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.
com.pacscloud.gateway
server.dicom
DicomNetwork
doStartService()
doStopService()
getAETitle()
getRemoteConn()
getDevice()
registerServices()
Storage QueryRetrieve
doStartService()
doStopService()
doStartService()
doStopService()
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).
Patient
-patient name
Study
- study instance uid
Series
- series instance uid
Images
- sop instance uid
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. PACSs 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.
 V. WORKFLOWS AND DATAFLOWS Likewise, retrieve process execute the same workflow, but
PACS Cloud Gateway is responsible for communication as it accesses to blobstore to retrieve DICOM objects. In the C-
DICOM service following DICOM conformance statement and MOVE process, when a C-MOVE Request is received by a
send, query or retrieve information from PACS Cloud in a gateway, destination AETitle and query level is extracted from
transparent way to the DICOM client side. On one hand, the the command data. In order to solve moves between multi-
movement of images from modality to PACS Cloud happens institutional sites, a signal is sent to the receiver gateway (step
when acquisition devices send the studies to the PACS Cloud 5 and 6). In the storage process, the download process uses
Gateway (Fig. 8). multithread and multiple objects are downloading at the same
time. On the other side, gateway starts a DICOM C-STORE
(7)
(2)
process with a negotiation to storage repository. Each object
PACS Cloud
Master Index (5)
successfully transferred from the blobstore is decrypted with
study session key and DICOM C-STORE process sends the
PACS Cloud
Gateway
PACS Cloud
Gateway object to storage repository. After all objects have been
transferred to the local repository association, the C-Move
DICOM
C-STORE (3) PACS Cloud
DICOM
C-FIND/ (4)
DICOM
(9) C-STORE
Response is sent to the C-Move requester entity.
(1) Slaves (6)
C-MOVE
(Cloud (8)
Modality
Devices Providers) VI. RESULTS
Workstations
A new PACS solution, which is able to store medical
studies in the cloud safety, has been developed. The data are in
Figure 8. PASCS Cloud Gateway - generic workflow the cloud, but the provider cannot do anything with it because
they are all ciphered and the keys live in Master Index, where
A. Storage Service cloud provider does not access. PACS Cloud Gateway grants
In the storage process, gateway is waiting for DICOM interoperability with DICOM devices working as a tradition
requests. The DICOM upper layer is maintained by dcm4che2, PACS archive from DICOM clients side perspective.
which deals with association and low-level protocol. Furthermore, from the administrators side, it reduces
Nonetheless, the transfer capability, AEtitles, delays and other drastically the IT infrastructures and brings new management
important DICOM issues in protocol need to be customized. facility in multi-site institutions with shared PACS.
All those settings are loaded from Master Index.
A. Performance measurements
In the storage workflow, modalities produce images and The prototype was tested through several study cases with a
send images operating with DICOM communications with C- huge amount of DICOM images of different modalities, stored
STORE command. Before it happens, modality needs to know in multiple providers: Google Storage and Amazon S3. In all
which SOP classes and PACS support transfer syntaxes. In step the tests the solution proved to be robust, enable to store, query
of this procedure, the gateway receives a DICOM ASSOC and retrieve all expected studies.
REQUEST to verify if server supports the SOPs. Following
the numeration in Fig. 8, in step (1) the acquisition devices To evaluate the software in performance and robustness,
invoke a C-STORE command, and data flows to the PACS PACS Cloud was tested several times using a data set of 6
Cloud Gateway. When the storage process is finished, PACS studies containing 855 DICOM files. There are a couple of
Cloud Gateway will send the metadata to the slaves database modalities on those studies: Cardiac XA, US, MR, CT. We
providers and to the Master Index (steps 2 and 3). Note that all have used the campus Internet connection and the gateways are
images upload to the Cloud are encrypted with AES algorithm. running Pentium4, with a 2,6 GHz processor and 2GB RAM.

B. Query/Retrieve Service We made several trials of storage and retrieve with Amazon
S3 and Google Storage, considering just average times of both
The Query/Retrieve process is subdivided in two DICOM process. It includes upload and download processes under
independents commands: C-FIND and C-MOVE, where the HTTP and DICOM communication from/to gateway to
C-FIND is associated with the queries and the C-MOVE with DICOM devices.
image objects retrieve action.
There are average measurements, result of several trials
On the other hand, the query and retrieve process are with different modalities. We did the tests with two blobstores
executed from workstations. In the query process there is no providers: Google Storage and Amazon S3 (Table I).
communication with blobstore. PACS Cloud gateway just
requests information to the indexes (step 5, 6 and 7). The C- TABLE I. STORAGE MEASUREMENTS
FIND request contains query items that can be a sub-set of
!"#$%&'( )*+,&%-. /"%01-+!2 3""4%-+5.6 789+9:+5.6
DIM fields and can contain a wildcards elements in search
!" # $ %&'( )&*)
like, for instance, in patients name. According with query !" $+ ( *&%% ,&#+
specificity, it can be executed directly in the DIM Cloud Slave !" $# '&( ((&$) %,&-(
Database (step 6). If the patients name is referred in query ". (#' $)&* %)&#$ (,&$,
items or this contains wildcard, there is a query for Master /01 (%) #-&* *,&*- #,&-)
Index. In the end, gateway will collect both data and send C- ". %-% (+) ((#&), $'$&)'
FIND Response with matchs result. The results were analyzed, and seems that there are
different measures between different providers (Fig. 9), which
means that for each provider the solution can be tuned, for healthcare institutions. The characteristics of the presented
improving the performance. PACS Cloud grant a great scalability and reliability of data. It
has a significant impact on healthcare institutions, which
&$!"!!# allows the reduction of datacenters 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.
+,,-./#01,23-/#

%!!"!!# 450#06# 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
Figure 9. Results for Storage process public data might not be accepted in some countries because
they force to know the location where the information is stored.
The download process is faster than upload as can be seen Nevertheless, PACS Cloud Gateway allows storing the medical
in the results. (Table. II). data in private cloud. Thus, the presented solution is compliant
with these laws and possible to deploy in the real environment.
TABLE II. RETRIEVE MEASUREMENTS
ACKNOWLEDGMENT
!"#$%&'( )*+,-./"0/0&%-1
2"%*+-/!3 4""5%-/617 89:/:;/617 Lus 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,
/01 )%' #*&. )(&# ),&# Needham T: A medical image archive solution in the cloud. In:
"- %*% )(' *#&, *$&% Software Engineering and Service Sciences (ICSESS) - IEEE
International Conference Beijing: 431-434.
Likewise in storage process, the retrieve process is faster in 2. Philbin J, Prior F, Nagy P: Will the Next Generation of PACS Be
Google Storage than Amazon. However, the last 3 studies are Sitting on a Cloud? Journal of Digital Imaging:1-5.
3. Yang C, Chen C, Yang M: Implementation of a medical image
slower in Google Storage (Fig. 10). The tests were performed file accessing system in co-allocation data grids. Future
in a shared connection, and without dedicated link to the Cloud Generation Computer Systems 2010.
Providers. Thus, the results vary due to Internet latency and 4. architecture AOwie: Architectural strategies for Cloud
noise of ISP (Internet Service Providers). 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.
'!"!# ,--./0#12-34.0# 9. Amazon Simple Storage Service [https://s3.amazonaws.com/ ]
561#1&# 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.
Figure 10. Results for retrieve process Web page, http://aws.amazon.com/solutions/case-studies/tc3-
health/ In.
Besides the security problems, PACS cloud will also solve 14. DICOM-P3: Digital Imaging and Communications in Medicine
the problems regarding resizing and the maintenance of (DICOM), Part 3: Information Object Definitions. In.: National
Electrical Manufacturers Association; 2001.
datacenter, as well as its reliability, interoperability and
15. Google App Engine (GAE) [http://code.google.com/appengine/]
performance are beyond expectations. The PACS Cloud 16. Corporation M: Windows Azure Platform. In.
Gateway is a fundamental component on this process 17. Amazon Webservices (AWS) [http://aws.amazon.com/]
18. Eucalyptus [www.eucalyptus.com]
VII. CONCLUSION 19. dcm4che sourceforge project
[http://sourceforge.net/projects/dcm4che/.]
PACS Cloud Gateway is very important to grant 20. jclouds: multi-cloud library [http://code.google.com/p/jclouds/]
interoperability with DICOM devices, which is very important 21. RESTlet framework [www.restlet.org]

View publication stats