A DICOM RELAY SERVICE SUPPORTED ON CLOUD

RESOURCES

Luís A. Bastião Silva, Carlos Costa and José Luis Oliveira

University of Aveiro, IEETA/DETI, 3810-190 Aveiro, Portugal

Keywords: PACS, DICOM, Medical imaging, Telemedicine, Teleradiology, Cloud computing.

Abstract: Over the past decades, healthcare institutions adopted Picture Archive and Communication Systems in their

workflows. The exchange and interaction between different equipment is performed with Digital Imaging

Communication in Medicine (DICOM), which is a very extensive protocol covering many areas of imaging

laboratories. However, the communication of a wide domain composed by several medical institutions is

not well supported. This paper presents a solution to share DICOM services across healthcare institutions.

The proposed implementation is supported on public cloud resources, creating the opportunity to exchange

information between medical devices across several institutions.

1 INTRODUCTION

The adoption of collaborative work has greatly

increased in healthcare in the past over decade and

the exchange of medical data across institutions is

already quite common in several modalities (Huang,

2004). Its importance has increased due to cost

saving for the medical institutions and also because

it can be used in several areas, such as expertise

consultation, cooperative environments and sharing

of images between multiple image centres.

Nowadays, PACS (Picture Archiving and

Communication System) is one of most valuable

tools to support medical decision and treatment

procedures. A PACS is a key point to store, retrieve

and distribute medical images in the various steps of

the clinical practices. Digital Imaging

Communication in Medicine (DICOM) supports the

distribution of the medical imaging, although this

standard is oriented to a single institution. The

communication of a wide domain composed by

several medical institutions is still a challenge.

Commonly, the image repositories or PACS archives

are not shared between medical centres due to

technical challenges and security concerns.

Although DICOM standards support SSL/TLS

layers, there are many medical devices that do not

support these features. Moreover, DICOM networks

are blocked by the firewall to access from outside of

the institutions to keep data safety in the intranet.

This prevents users located outside the institution

from accessing the PACS archive. Medical

institutions often use VPN (Virtual Private

Networks) to share medical resources. However, this

solution requires point-to-point configurations,

which is not scalable. Other possibilities to exchange

exams between medical institutions are processed

through CD/DVD delivered, for instance, by

conventional mail or using email.

Cloud computing is largely used to share files

over the Internet and allow users to communicate

with each other using external infrastructures. This

technology allows access to applications and data

without any infrastructure inside the medical

institutions (Rimal and Choi, 2010). However, there

are also some important issues that must be

considered during the implementation of a solution

(infrastructure and/or application) in a public Cloud

provider (Rosenthal et al., 2010). There are critical

concern related with data security and privacy.

The main idea of this paper is to promote

DICOM inter-institutional communications,

allowing the establishment of shared workflow and

exchange of documents across them. The proposed

DICOM relay service aims to be a communication

broker, allowing search, store and retrieve of

medical images over a group of hospitals, in

different sites. This solution allows, for instance,

remote access to the institutional PACS storage. The

communication between different islands is

supported on the cloud services, but it keeps the

409

A. Bastião Silva L., Costa C. and Oliveira J..

A DICOM RELAY SERVICE SUPPORTED ON CLOUD RESOURCES.

DOI: 10.5220/0003788104090412

In Proceedings of the International Conference on Health Informatics (HEALTHINF-2012), pages 409-412

ISBN: 978-989-8425-88-1

 2012 SCITEPRESS (Science and Technology Publications, Lda.)

interoperability with the devices adopted by the

medical community. The proposed DICOM routing

mechanism has a transparent application to end-user

maintain the standards used by medical imaging

devices and repositories.

2 BACKGROUND

2.1 Collaborative Work in Medicine

Currently, most equipment in medical institutes uses

the DICOM standard to communicate, store and

visualize information. In theory, DICOM standard

solved all issues regarding the communication

between different collaborators, but it still has some

gaps in real environments, mainly in inter-

institutional cooperation, which have barriers in

“many-to-many” collaboration.

Teleradiology is one of important cooperative

areas in medicine and it increased in the last two

decades. The medical centres cannot afford

specialists from all areas and it is usual to outsource

some services, including report of procedures

produced inside institutions. There are hospitals and

small centres that have technicians and acquisition

devices to perform exams. However, in some

modalities, i.e. Computer Radiology (CR), they do

not have enough specialists to report these exams. In

these cases, the remote report is a very common

practice. There are also other user cases like, for

instance, the telework scenarios, where healthcare

professionals need to have remote access to medical

repositories and information systems of their

institutions.

To summarize, telematics platforms appear as

fundamental tools to support medical services and

processes. Moreover, these new technologies can be

decisive in some scenarios, mainly in regions with

difficult communication accesses or with few

inhabitants.

2.2 Cloud Computing

Cloud computing is a risen technology that allows

enterprises to hold scalable resources without having

any IT infrastructure. There are several cloud

providers, such as, Amazon AWS, Google and

Rackspace that embraces many areas, since storage,

databases, signalling and message queue. These

providers supply elastic computing power and

unlimited storage (Vaquero et al., 2008); (Oliveira et

al., 2010) to their customers.

There is a huge amount of interest in the IT

industry to migrate services to Internet Cloud

platforms (Hajjat et al., 2010). In order to response

to their request, many cloud companies have been

created to meet their demands. There was a

significant effort from Cloud providers to offer new

features to clients. For instance, Amazon Web

Services has released many services to fulfil their

customers’ requirements: S3 (S3, 2011), SQS,

SimpleDB and many others. In turn, Google

AppEngine (Google), Windows Azure (Microsoft)

and many others improved their solutions with new

APIs to overcome the challenges of their targets.

It is evident that the computing-as-utility is a

business model becoming prevalent in the electronic

world and numerous institutions are adopting these

solutions. Furthermore, the emergence of Cloud

computing providers creates a great opportunity to

tackle the costs of purchase hardware and software.

The market is changing and there are new

paradigms to deploy applications and to store

information that are always available on the Internet.

We believe that medical solutions will also adopt

these new models to improve their business

processes. For example, Microsoft Healthvault

(Microsoft, 2011) provide a management panel

easier to access for the personal health information,

always available.

3 ARCHITECTURE

3.1 Description

Cloud computing is largely used to share files over

the Internet, and many examples can be pointed out,

such as, Dropbox (Dropbox, 2011) and Gmail

(Google, 2011a). Moreover, Cloud providers offer

high availability and scalability of their services.

Our DICOM relay architecture takes advantage of

the cloud computing services to exchange

information between several locations.

The communication between the components of

the digital medical laboratories is mainly used

through DICOM. This protocol runs over TCP/IP

protocol, but contains its own addressing model

through the AETitle that identifies the medical

device (DICOM-P7, 2009). Due to network filters

(i.e. firewall’s), this communication does not work

in WAN (Wide Area Network) scenarios. To extend

the communication to different institutions, the

proposed approach takes advantage of the DICOM

addressing mechanism to route the information to

the correct location (i.e. AETitle is the DICOM

HEALTHINF 2012 - International Conference on Health Informatics

410

Figure 1: Relay architecture: the boundary Router assures the communications between DICOM devices and the Cloud.

address mechanism). The public cloud infrastructure

is used as a communication mechanism to support

information forwarding among the involved entities

through these routes. Furthermore, additional Cloud

provider support is simplified due to a plugin-based

system. To create an abstraction over the cloud

storage, we have developed a Cloud I/O stream

mechanism that allows writing in the cloud storage

as a data stream. New cloud providers can be easy

supported, by implementing the interfaces supplied

by Cloud I/O.

3.2 Components

The proposed DICOM relay service has two main

goals: assure the secure/reliable connection between

the actors and create a simple solution to access the

internal medical repositories “anytime and

anywhere”. Our architecture (Figure 1) contains two

major components: 1) DICOM Bridge Router and 2)

DICOM Cloud Router.

3.2.1 DICOM Cloud Router

The DICOM Cloud Router (Router) is a software

component that is mainly responsible to handle the

DICOM services and forwarding messages to the

correct place. To do so, it uses AETitle routing

tables, i.e. for each AETitle belonging to the

DICOM network domain, it associates the type of

services that is providing and the username of the

Router, which will allow to reach the correct router

to forward the messages. In fact, manual

management of those tables are actual practices

because the DICOM standard does not provide a

mechanism to auto-discovery of the DICOM nodes.

Also, for security reasons, only allowed medical

devices should be accessed from outside the medical

institution and those tables also work as access

control list. So, the Router has a graphical interface

to setup the IP, port and the services available inside

the medical institution.

Real world objects were mapped directly in the

DICOM standard. For instance DICOM equipment

is represented as a “Device” in the defined concepts

of the standard. The Router supports multiple

devices (i.e. as many as are online in the WAN

DICOM network), each one with a different AETitle

and transfer syntaxes (i.e. the data codification

supported).

Finally, each medical institution or isolated

DICOM network that wants to share services to the

WAN DICOM network needs to run a Router inside

the private network that will work as a standard

DICOM node supporting several services.

3.2.2 DICOM Bridge Router

The DICOM Bridge Router or Bridge, works as a

relay mechanism between different DICOM Cloud

Routers dispersed over several locations. This

component works in a partnership with the cloud

providers. The huge amount of information that

flows in WAN network needs to be

uploaded/downloaded to the cloud providers.

DICOM Bridge Router is an important part of the

A DICOM RELAY SERVICE SUPPORTED ON CLOUD RESOURCES

411

architecture because it stores residual information

about all devices (i.e. AETitles) and corresponding

services supported. Moreover, it has accounts from

routers and a list of cloud providers that routers can

use to store temporary information. It needs to be

always available over the Internet because routers

need to write information in the Bridge to provide

communications. It can be deployed in several

places like, for instance, in a private cloud detained

by a medical institution or a public cloud provider.

Due to privacy concerns, we strongly recommend

deployment of this component in a trustable provider

or in-house (i.e. medical institutions).

The management of the diverse Routers is

supported by a temporary information system

located on the Bridge and it is accessible through a

RESTful web service. Only registered users have

access to the DICOM WAN Network. Moreover, the

Bridge is a very important component because it

stores the session key used to cipher DICOM

messages of an association. Thus, it should be

located in a trustable location, to safeguard the

architecture.

The Bridge is considered the main component of

the architecture because it performs the management

of the relay service. It only contains a reduced

amount of information, and during the dataflow it

just store a minimum amount of data, i.e., the

confidential shared key. The remaining information

is transmitted through the cloud in a ciphered mode.

It is used two different cloud services: blobstore and

signalling. The Cloud providers supply, on the one

hand, temporary storage of blinded data (encrypted

DICOM objects/commands) and, on the other hand,

a signalling service that allows establishing

communication in real time between the routers.

4 CONCLUSIONS

The presented solution allows DICOM standard

communication between medical devices located in

distinct institutions. The proposed architecture

allows creating a federated DICOM network across

distinct medical institutions, with a unique view of

all resources.

Our DICOM relay service does not need

complex setups to start communicating with external

repositories, allowing interoperability with any the

DICOM standard device.

With this system, radiologists can work

remotely, in the same way that they do in the

hospital, without changing their methods.

REFERENCES

Dicom-P7 2009. Digital Imaging and Communications in

Medicine (DICOM), Part 7: Message Exchange.

National Electrical Manufacturers Association.

Dropbox. 2011. Dropbox Service [Online]. Available:

www.dropbox.com [Accessed June 2011].

Google. 2011a. Gmail [Online]. Available: www.gmail.

com [Accessed June 2011].

Google. 2011b. Google App Engine (GAE) [Online].

Available: http://code.google.com/appengine/

[Accessed June 2011].

Hajjat, M., Sun, X., Sung, Y.-W. E., Maltz, D., Rao, S.,

Sripanidkulchai, K. and Tawarmalani, M. 2010.

Cloudward bound: planning for beneficial migration

of enterprise applications to the cloud. SIGCOMM

Comput. Commun. Rev., 40, 243-254.

Huang, H. K. 2004. PACS and imaging informatics: Basic

Principles and Applications.

Microsoft. Windows Azure Platform [Online]. Available:

www.microsoft.com/windowsazure/ [Accessed June

2011].

Microsoft. 2011. Microsoft HealthVault [Online].

Available: www.healthvault.com [Accessed May

2011].

Oliveira, D., Bai„O, F. A. and Mattoso, M. 2010. Towards

a Taxonomy for Cloud Computing from an e-Science

Perspective. Cloud Computing, 47-62.

Rimal, B. and Choi, E. A Conceptual Approach for

Taxonomical Spectrum of Cloud Computing.

Ubiquitous Information Technologies & Applications,

2009. ICUT '09. - Proceedings of the 4th International

Conference 2010 Fukuoka. IEEE, 1-6.

Rosenthal, A., Mork, P., Li, M. H., Stanford, J., Koester,

D. and Reynolds, P. 2010. Cloud computing: a new

business paradigm for biomedical information sharing.

J Biomed Inform, 43, 342-53.

S3, A. 2011. Amazon Simple Storage Service [Online].

Available: https://s3.amazonaws.com/ [Accessed June

2011].

Vaquero, L. M., Rodero-Merino, L., Caceres, J. &

Lindner, M. 2008. A break in the clouds: towards a

cloud definition. ACM SIGCOMM Computer

Communication Review, 39, 50-55.

HEALTHINF 2012 - International Conference on Health Informatics

412