E-Epr

E-EPR: A cloud-based architecture of an electronic emergency patient record

M. Poulymenopoulou
Department of Digital Systems
University of Piraeus
Piraeus, 185 34, Greece
+302104142231
[email protected]



F. Malamateniou
Department of Digital Systems
University of Piraeus
Piraeus, 185 34, Greece
+302104142430
[email protected]


G. Vassilacopoulos
Department of Digital Systems
University of Piraeus
Piraeus, 185 34, Greece
+302104142430
[email protected]



ABSTRACT
Limited access to past medical information of emergency cases during
emergency healthcare delivery is a proximal cause of increasing emergency
care length and risk. Hence, there is a need for ubiquitous access to
integrated emergency patient information at the point of care in order to
effectively and efficiently manage emergency cases and to apply the
appropriate diagnosis and treatment procedures. In this paper, a cloud-
based service-oriented architecture (SOA) is described for the
implementation of an electronic emergency patient record system (E-EPR)
that provide functionality for managing (retrieving, transforming,
exchanging and storing) emergency case information and patient critical
medical information in a distributed and ubiquitous manner that supports
several platforms and applications. The proposed system can be easily
integrated with existing ambulance service and hospital information systems
because of the use of open-wide standards. An experimental implementation
of the system in a simulated laboratory environment is presented.


Categories and Subject Descriptors
J.3 [LIFE AND MEDICAL SCIENCES]: Medical information systems


General Terms
Design


Keywords
SOA; BPEL; cloud computing, amazon web services, CDA


INTRODUCTION

Emergency healthcare delivery involves a variety of activities
(administrative, paramedical, nursing and medical) that are performed from
the time of a call for an ambulance until the time of patient's exit from
the emergency department of a hospital and is divided into pre-hospital and
in-hospital emergency healthcare processes. Pre-hospital emergency care is
provided by medical and/or paramedical staff of the ambulance at the place
of incident and en-route (during the case transfer from the place of
incident to the emergency department of the selected hospital) while in-
hospital emergency care is provided by medical, paramedical and nursing
staff of the emergency department selected [9, 16].

Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy
otherwise, to republish, to post on servers or to redistribute to lists,
requires prior specific permission and/or a fee.
PETRA'11, May 25 - 27, 2011, Crete, Greece.
Copyright ©2011 ACM ISBN 978-1-4503-0772-7/11/05 ... $10.00
During emergency case management at the emergency department of a hospital,
readily access to portions of past patient data and to pre-hospital care
data enables proper diagnosis and treatment, eliminates the risk for
medical and medication errors and streamlines the emergency healthcare
process. In addition, emergency case data constitute a vital source to
understanding various public health problems and to identifying new and
emerging health threats [9,10,25].

Emergency medical services (EMS) are time-critical both medically (e.g.,
rapid transportation in case of major trauma) and on resource management
basis [5,9,10]. For example, medical and paramedical personnel of the
ambulance service have to perform in a timely and accurate manner with
limited resources on both medical equipment and IT support. Most ambulance
services currently use paper-based records or isolated desktop-based
information systems with no linkage among them and/or with hospital
information systems and electronic patient record (EPR) systems [16,17].
Thus, pre-hospital emergency case data is usually transferred to the
emergency department of the selected hospital by the ambulance personnel in
paper.

This paper presents an electronic emergency patient record (E-EPR) as a
service on a cloud that aims at making available the information needed by
emergency department physicians at the point of care (e.g. on a tablet pc
or mobile phone). In particular, the system allows emergency department
physicians to access emergency case information that has been collected
during the pre-hospital emergency care process as well as selected portions
of patient information (e.g. patient allergies and chronic diseases) from
the patient's Personal Health Record (PHR) stored in a central repository.


The E-EPR is based on open-wide standards in order to provide easy
integration among emergency healthcare systems, hospital information
systems and patient PHRs, is web-based in order to be easily accessible by
any ambulance service and hospital, is scalable in order to scale up and
down according to the requested usage and is user-friendly and inexpensive
in order to be easily adaptable by every ambulance service and hospital
with minimal cost. The approach adopted supports the consolidation of
emergency healthcare data and selected patient data as well as their
semantic and structural transformations and their ubiquitous provision to
authorized participants to the emergency healthcare process.

As regards to technology, E-EPR is based on a service-oriented architecture
(SOA) that uses a cloud infrastructure. In the last few years, SOA has
emerged as an architectural style that allows easy integration of
heterogeneous applications by implementing web services as interoperable
interfaces [4,12,23,26]. Besides, new delivery models for software have
been emerging that allow enterprises to move away from traditional on-
premise applications that are hosted and run in their own data centers
[3,8,14]. Clouds shift the responsibility to install and maintain hardware
and basic computational services away from the customer (e.g., a laboratory
or healthcare organization) to the cloud vendor. This way, cloud computing,
cut down organizational costs in terms of both hardware and software
ownership and IT maintenance and can provide computational and storage
resources on demand based on a pay per use model according to application
requirements [6,15,18,20].

As a matter of fact, a BPEL process has been implemented to retrieve
patient information from disparate sources (PHRs and ambulance service
database servers), to transform it in the form of XML documents according
to the CDA release two specification, to send it to appropriate recipients
and to store it to virtualized servers. This BPEL process is executed on
virtualized cloud servers and some process activities call cloud services
in order to retrieve/store documents on cloud servers and to transfer
messages to appropriate recipients and among web services. In addition, a
mobile application was developed to enable the execution of the BPEL
process and the view of the CDA document with emergency case and selected
patient data through mobile devices. An experimental prototype
implementation of the E-EPR is also described.


BACKGROUND and PROBLEM STATEMENT

In healthcare, the use of open standards on cloud computing have been
proposed as a means for maintaining health records, monitoring patients,
managing diseases and cares more efficiently and effectively, or
collaborating with peers and analyzing data [19,23,27]. Currently, there is
a series of initiatives that make efforts to build a cloud-based platform
to permit secure data sharing among the institutions so as to improve the
quality of consumer care. Some examples for electronic, personally-
controlled health records delivered as SaaS are the Microsoft Corporation
Health Vault Program, the Intel Corporation Dossia and the Google Health.

This research stems from our involvement in a low-budget project concerned
with the implementation of an electronic emergency patient record (E-EPR)
to support the information needed by ambulance service and emergency
department physicians during emergency healthcare processes [16,17].
Ambulance service and hospital emergency departments had implemented a
number of heterogeneous and isolated systems. In particular, the ambulance
service was using an information system with no linkage with emergency
departments' information systems and patient PHRs. In addition, ambulance
personnel had no access to medical data of the patient at hand, thus
increasing emergency case risk. The E-EPR requirements included the
interconnection of the existing information systems of ambulance service
and emergency departments and patient PHRs with minimal investment on
hardware and software in order to reduce the total cost of ownership (TCO)
for the ambulance service and the hospitals. In this respect, designing the
system architecture was confronted with a number of confounding issues,
including the selection of the existing information systems functionality
to be exported and used by the new system, the system implementation using
organizations' existing infrastructure or a cloud computing infrastructure,
the use of a public, private or hybrid cloud solution, the selection of the
appropriate standards to transform patient information into a common format
and structure, in addition to issues related to supporting technologies and
to patient information security issues [1,7,15,18].

From the E-EPR analysis, the functional, technical and economic
requirements were identified that should be satisfied by the E-EPR and
appropriate solutions were found. Thus, it was decided to use the cloud
computing infrastructure for the implementation of the E-EPR and its
provision as a service to authorized users. This is a lightweight solution
on the client-side as the only interface to the E-EPR is a web browser.
This also enabled the provision of E-EPR through tablet PCs or mobile
phones of authorized physicians of ambulance service and hospital emergency
departments at the point of care [11]. In addition, the provision of the E-
EPR as a service makes it possible to easily incorporate other ambulance
services and hospitals emergency departments.

Although there are definite benefits to cloud computing, there are also
many potential risks, because cloud computing combines new technology with
many unproven vendors and service providers. Security, reliability and
manageability need to be key elements in the planning and selection
processes for the use of private and public cloud services [1,13,27]. When
sensitive information like patient medical information is to be transferred
on a public cloud, the security issues are sometimes a barrier for cloud
computing adoption. However, it is possible with the use of appropriate
security techniques like encryption, access control policies, data backups,
audit logs etc. to safeguard data in the cloud and maximize the healthcare
benefits of cloud offerings [1,2,27]. In addition, as concerns the security
on public and private clouds, there is not strong evidence that private
clouds are more secure than public clouds especially for those offered by
proven and reliable vendors that provide advanced security features.

For the E-EPR the public Amazon cloud was used as it provides a secure,
flexible, scalable, low-cost cloud computing platform for businesses of all
sizes all around the world with no entry costs and with a pay per use model
[22]. According to E-EPR architecture, sensitive patient information
(emergency case data and past patient data) is transformed into a CDA
document and stored in Amazon cloud servers. In order to ensure that this
information is kept safely and that is accessed only by authorized users,
the amazon security features were used which enable the creation of HIPAA
compliant medical data applications [2]. Thus, in order to satisfy HIPAA
privacy and security rules, A) all the documents stored on the cloud are
first encrypted, B) accesses to the stored documents are controlled by
access control policies based on the fundamental least privilege principle,
C) auditing logs are created for every server instance and D) the automated
data backup procedures and the disaster recovery mechanisms of Amazon were
used.















Figure 1: The E-EPR service on Amazon Cloud


For the E-EPR implementation, Amazon's Elastic Compute Cloud (EC2) was used
to configure customized operating systems and to install the required
software platforms. On request, an instance is booted on a physical host in
the infrastructure and may be used like a dedicated physical host shortly
after the request [20,22]. In case of overload, additional instances can be
started on demand. The E-EPR is based on a service-oriented architecture,
thus, the Business Process as a Service (BPaaS) model was used in order to
deploy and execute the BPEL process and the web services. Amazon does not
provide a BPaaS model but this can be achieved by the deployment of a SOA
platform on Amazon EC2 instances. Many popular vendors like Oracle, IBM,
WSO2 and SUN provide Amazon Machine Images (AMIs) containing their
platforms that can be used with Amazon EC2 to easily run pre-configured
instances [7,24,28].

The BPEL process created and configured on Amazon cloud also call other
Amazon web services from BPEL "invoke" activities as third party partners.
For example, the Amazon Simple Storage Service (S3) was used to store and
retrieve documents on cloud servers and the Amazon Simple Queue Service
(SQS) was used to transfer messages among web services or among web
services and clients. Figure 1 illustrates the E-EPR service on Amazon
cloud with the use of AWS.


E-EPR ARCHITECTURE

The E-EPR architecture described involves the ubiquitous provision of
emergency cases information and patients critical information (e.g.,
patient allergies and chronic diseases) to the ambulance service, ambulance
and hospitals emergency departments physicians. A schematic view of the E-
EPR architecture is shown in Figure 2.































Figure 2: E-EPR architecture

At each of the healthcare organizations (e.g., ambulance services,
hospitals) there exist database servers where patient data is stored, the
existing information system and a local security server that enforces its
security policy. At the Amazon EC2 virtual images exists the SOA platform
that consists of the Database Server, the Business Process Server and the
Application Server. The Business Process Server hosts the BPEL process and
the application server hosts the web services that implement the BPEL
process activities. In addition, on Amazon EC2 virtual images a global
security server has been deployed to enforce the global-wide security
policy. The emergency case and patient critical data (e.g., patient
allergies and chronic diseases) created in the form of XML CDA-based
documents are stored to and retrieved from the cloud servers by the Amazon
S3 and are made available to appropriate authorized recipients through a
message send by the Amazon SQS. This cloud service is used for storing
messages that they travel among web services and among web services and
clients, for ensuring that no message will be lost and that messages will
be always available [22].


Figure 3: BPEL process model designed using BPEL Eclipse Designer

On the mobile devices (tablet pc or mobile phones) of the ambulance and
emergency departments physicians there has been installed a mobile
application which is used in order to receive and view CDA documents (with
emergency case data and patient critical data). When a mobile application
is loaded on a mobile device of an ambulance service or emergency
department physician, the user is authenticated by the corresponding local
security server and a connection is established with the corresponding
existing information system.

In particular, during pre-hospital emergency healthcare delivery, emergency
case data is stored in the ambulance service database servers. The proposed
system architecture is intended to provide pre-hospital emergency case data
in a standard format and structure to ambulance and emergency department
physicians. Thus, a BPEL process has been created which is either
automatically triggered upon actions performed on ambulance service
existing information system (context information) or is executed on-demand
by authorized users (ambulance and emergency department physicians). For
example, this process is executed automatically on ambulance arrival at the
point of incident in order to provide to ambulance physician timely and
accurate access to cases emergency data entered so far (e.g. cases symptoms
entered to the system at the time of ambulance call) and to past patient
data. This process is also executed automatically on ambulance arrival at
the emergency department in order to provide to emergency department
physicians access to all pre-hospital emergency case data and to past
patient data. On process execution, web and cloud services are called that
retrieve pre-hospital emergency case data from ambulance service database
servers and designated portions of medical data from the patient's PHR,
transform this data into a CDA document which is stored in the cloud
servers and send this document to authorized users tablet pc or mobile
phone. In this way, it is assured that timely and accurate patient
information is made available at the point of care when needed. This BPEL
process can also be executed manually by authorized users of ambulance and
emergency department through the mobile application loaded on their mobile
devices. Figure 3 illustrates a schematic view of this BPEL process.


SECURITY ISSUES

In healthcare, protecting the confidentiality of health information, whilst
at the same time allowing authorized users to access it conveniently, is a
crucial requirement. Medical information is highly sensitive.
Confidentiality of such information must be kept strictly, yet at the same
time it must not hinder patient care by denying legitimate access requested
by authorized users (doctors, nurses etc). In cases where patient
information is selected to be moved on a cloud infrastructure an additional
risk is posed. The issues of end-to-end security and end-to-end privacy
within the cloud computing world are more sophisticated than in a single
data center not facing the Internet [13,16,27]. That's why strict security
mechanisms should be applied in order to provide a secured system that
ensures authorized access to services (BPEL process, web and cloud
services) and patient information.

In particular, in order to satisfy HIPAA privacy rules the following
security techniques were used: patient data and documents on the fly and on
the cloud were encrypted using 256 bit AES algorithms, the Amazon EC2
firewall was used to restrict the traffic to each EC2 instance by source IP
address and the patient documents stored on cloud servers were allowed to
be accessed only though Amazon S3 using Secure Socket Layer (SSL) encrypted
endpoints. In addition, Amazon S3 object level access control feature was
used, to control access to patient documents stored on cloud servers. As
concerns, HIPAA security rules the following security techniques were used:
A) the Amazon EC2 activity and audit logs for the virtual servers, B) the
Amazon S3 automated backups and additionally snapshots were taken of Amazon
EC2 data which are automatically stored in Amazon S3 and are replicated
across multiple Availability Zones and C) the disaster recovery mechanisms
offered by the AWS like that Amazon EC2 instances can start very quickly in
case of a server failure [1, 2, 22].

Additionally an authorization model was developed to provide discretionary,
role-based and context-aware authorizations. At the ambulance service, a
local security server was deployed to provide authorization services that
concern locally stored emergency case data access and BPEL process
invocation. At hospital emergency departments, local security servers were
deployed to provide authorization services that concern only BPEL process
invocation. In addition, a global security server was deployed on Amazon
EC2 images in order to provide authorization services with regard to: (a)
BPEL process executions, (b) web and cloud services executions, and (c) XML
CDA documents access through web and cloud service execution. As regards
data access to patients PHRs existing on the central repository, it is
assumed that is controlled by the repository access control policy and is
not analyzed in this paper.

The XML Access Control Language (XACML) was used to implement the
authorization services on ambulance service, hospital emergency departments
and cloud infrastructure [21,27]. It is a declarative access control policy
language implemented in XML and a processing model, describing how to
interpret the policies. Authorizations for XML CDA document accesses were
specified at the level of XML schemas (consisted of schema elements) and
are applicable to all XML documents that are instances of the XML schemas
[16,21].

The XACML policy files existing at the local security servers of ambulance
service and hospital emergency departments, specify role- and context-based
authorizations to indicate which subject (in terms of role) and under which
context (e.g time, location) can invoke the BPEL process existing on cloud
infrastructure. The contextual information at access time is usually
depends on actions performed to the local information system of ambulance
service or hospital emergency departments. For example, when the actual
time of ambulance arrival at the place of incident or at the case emergency
department is entered to the system (time constraint) by an authorized
ambulance service doctor (role-based authorization) belonging to a specific
location (IP constraint), the BPEL process is executed automatically in
order to send pre-hospital emergency case data and patient critical medical
data to ambulance or hospital emergency department physicians,
respectively. In addition, at ambulance service, role-based and context-
aware authorization rules were written to specify which subject (role-based
authorization) can access which subset of locally stored emergency case
data only during which web service execution (context-based authorization).


The XACML policy files existing at the global security server specify role-
and context-based authorizations to indicate which subjects (in terms of
role) and under which context (user's location etc) can execute which BPEL
process, which web and cloud services and access which XML CDA documents.
As concerns BPEL process execution, when a process instantiation request is
made by an authorized user according to its organization local security
policy, this request is evaluated according to the authorization rules
specified at the global security server. These authorization rules specify
which subject (role-based authorization) and from which location (IP
constraint or ambulance location) can execute the BPEL process. Thus,
users, roles and authorization rules specified on cloud infrastructure must
be compatible with those specified on ambulance service and hospitals
emergency departments. For example, if a local authorization rule states
that a user with the role "ambulance service doctor" can execute at a
certain time (on ambulance arrival at the emergency department) the BPEL
process for the patient currently en-route, this authorization rule must be
compatible with the one existing on cloud's authorization policy. In
addition, on cloud's authorization policy other authorization rules must
exist that will specify that the user with the role "ambulance service
doctor" can also execute for the patient en-route and at the same time the
web and cloud services that are invoked by the BPEL process.

With regard to XML documents, the authorization rules indicate which
subject (in terms of role) can access which CDA documents (instances of XML
schemas) and during which web or cloud services execution. These rules are
copied to the Amazon S3 access control rules, each time a new CDA document
is stored on a cloud server with the use of Amazon S3.


E-EPR IMPLEMENTATION

To illustrate the main features of the E-EPR functionality described above,
a prototype implementation of a SOA service on Amazon cloud is described
for use in the domain of emergency healthcare delivery. The field work of
the implementation involves a cross-organizational emergency healthcare
process that begins with a patient call for an ambulance and ends with
patient exit from the emergency department of a hospital.


Figure 4: The WSO2 management console with the BPEL process information

The prototype was implemented on Amazon cloud infrastructure where WSO2
carbon platform was deployed as a platform as a service (PaaS). The web
interface provided by WSO2 Stratos was used for deploying, running and
monitoring the BPEL process and the web/cloud services [24]. BPEL designer
on eclipse IDE was used for developing, testing and debugging the BPEL
processes. The Java 2 Platform Enterprise Edition (J2EE) and the Web
Services Tools on eclipse IDE were used to create, publish and test the web
services and the BPEL process. The Mobile Tools for Java 1.1.0. plugin of
eclipse IDE was used for the development of the mobile application loaded
on users mobile devices. In figure 4 the WSO2 management console with the
BPEL process information is presented.

The CDA documents created by the BPEL process were categorized into
document types that concern pre-hospital emergency case data collected by
the ambulance service (e.g. ambulance service record) and the patient
critical data retrieved from patient PHR (e.g. critical data summaries).
Each document type corresponds to an XML schema that provides a structural
description of the header part, the body part and the data types of patient
XML documents (instances of the corresponding XML schemas). All XML schemas
conform to the XML schema proposed in the CDA release two specification,
while the International Classification of Primary Care - 2 symptom codes
(ICPC-2) and SNOMED terminology systems are used for coding medical data
[16,17,26].


1 BPEL process implementation

According to the emergency healthcare process, an ambulance service doctor
selects the ambulance that will transfer the case at a hospital emergency
department. On ambulance arrival at the place of incident, the time is
entered on ambulance service information system by an authorized ambulance
service doctor and automatically is executed the BPEL process. The same
stands when the actual time of ambulance arrival at the hospital emergency
department for the case is entered to the system. For process execution,
the process input data is sent to WSO2 and a process instance is created
and started. The input data involves the user role, the emergency case
identification number, the patient's identification number (if available)
and the location from where this process is instantiated. Then, the
appropriate web and cloud services that implement the process activities
are executed according to the rules defined on the process model and to the
authorization rules defined in global security server.

When the BPEL process instance terminates, a SOAP message is send to the
ambulance service or emergency department (that he/she is assigned the role
of cases "attending physician") where is deserialized and the document in
presented to the appropriate tablet pc or mobile phone of the ambulance or
emergency department physician, respectively. This way, the CDA document
with emergency case data and patient critical data existing on cloud is
timely available at the point of care. The same stands when an ambulance or
emergency department physician manually requests the BPEL process execution
from the mobile application loaded on his/her mobile device.


2 Authorization service implementation

Authorization service is provided at two levels: locally at the ambulance
service and hospitals emergency departments and globally on the cloud. Each
local authorization server includes an authorization mechanism which has
been implemented using the XML access control markup language (XACML) by
Sun Microsystems [21]. Thus, XACML policy files have been developed that
contain role- and context-based authorization rules and are stored in the
local security servers.

Local security servers at ambulance service and hospitals emergency
departments complement the security features of the existing information
systems by enforcing role- and context-based authorizations with regard to
BPEL process invocation. As concerns the BPEL process, each time the
preconditions to trigger a context are satisfied (e.g. the actual time of
ambulance arrival at the emergency department, the assignment of role
"attending physician" to a user at the hospital emergency department) or a
manual request for process execution is received, a request is made to the
Policy Enforcement Point (PEP). The PEP forms a request using the XACML
request language that includes users role, context information and user
location and sends it to the Policy Decision Point (PDP). The PDP receives
and examines the request, retrieves applicable policies written in XACML,
determines if the BPEL process should be invoked by which role holders and
returns the access decision to the PEP. If the access decision is allow,
the process is executed.

As concerns locally stored emergency case data access at ambulance service,
when the appropriate web service makes a request of retrieving emergency
case data during the BPEL process execution, a XACML request is made to the
PEP including the user role that instantiated the BPEL process and context
information (the request is made though this particular web service that is
invoked by the BPEL process). The PDP receives and examines the request,
retrieves applicable policies written in XACML, determines which emergency
case data should be retrieved and returns the access decision to the PEP.
Then the web service retrieves authorized emergency case data.

For the implementation of the global security service, the WSO2 identity
server was used that provide sophisticated identity and security management
of enterprise web applications and services having support for XACML. Thus,
the WSO2 identity server as a service was used for creating users and roles
and for writing XACML policy files. With regard to BPEL processes and
web/cloud services executions, each time a request is performed from a role
holder, a XACML request is made to the PEP including user role, context
information (e.g. the location from where execution is requested), the
resource (BPEL, web/cloud service, CDA document) and the requested action
to be performed on resource (e.g. execution, access, storage). This request
is evaluated by the PDP and a XACML response is created that enables or
disables the requested action on the resource (e.g. BPEL process
execution).


E-EPR BENEFITS and EVALUATION

Among the benefits of implementing the E-EPR on Amazon cloud
infrastructure, will be the reduction of the total cost of ownership (TCO)
for ambulance service and hospitals emergency departments by moving a part
of their IT onto a suitable cloud. In addition, the hardware and software
systems management will be decreased and simplified because the maintenance
and management are offloaded to the cloud. Also, the effort for data backup
management will eliminate as Amazon cloud stores backups of users'
applications and data in multiple geographical locations [3,6,15]. If a
machine fails, others can take over, at the same location, or between
locations (for disaster recovery). If the ambulance service and hospital
emergency departments implement their own fault tolerance and disaster
recovery systems, management effort, additional software, hardware, and
space are required and additional risks are posed (users who manage
recovery poorly may lose all their data, e.g., in a flood) [19,28]. With
cloud computing it is ensured that patient data existing on cloud will not
be lost even in case of a server failure and that will be always available.

In addition, when the workload experiences significant change, resources
can be added or released in minutes. The cloud provides extra processing
resources during the peaks (within limits) when the transaction load
spikes, such as the case of many requests (e.g. in case of a physical
disaster) of the BPEL process that requires the emergency case data and
patient critical data transformation to CDA documents. On simulation tests
performed, it was found that response times of the BPEL process executions
were reduced by applying many servers, as opposed to running a single
server for hours [20].

For E-EPR evaluation we asked from physicians with experience in emergency
healthcare delivery to evaluate the system. User satisfaction is a
fundamental aspect and embraces satisfaction for the patient information
provided through the E-EPR. The user satisfaction is significantly higher
than that observed with the paper-based workflow used. Through E-EPR, pre-
hospital emergency case data and patient critical medical data will be made
timely available to the ambulance physician and to the cases attending
physician at the emergency department.

Perceived ease of use refers to the degree to which an individual considers
the usage of a system to be free of effort. Ease of use represents an
essential motivation for individuals' voluntarily use of the system, and
can affect their adoption decisions significantly [11,26]. The ease of use
of the E-EPR, as perceived by an individual, is significantly greater than
that of the paper-based workflow. That was obvious, as the users were able
to operate the E-EPR after quick education and training. In particular, the
automatic execution of the BPEL process and the CDA document presentation
on users mobile device, increased user satisfaction and adoption.


CONCLUDING REMARKS

Emergency healthcare play a vital role in the healthcare system as is
considered a window on the general health. Emergency case data analysis
allows a better understanding of the health needs of the public and is
considered very important in healthcare as they help to guide more
thoughtful and efficacious public health and medical interventions
[5,9,10]. In addition, the timely and ubiquitous provision of emergency
case data and critical patient medical data to the participating healthcare
organizations in the emergency healthcare process is considered important
for providing better medical treatment and reducing the cases risk. These
information requirements during emergency healthcare delivery can be
satisfied by the implementation of an electronic patient record (EPR)
system for emergency healthcare. On this paper, the implementation of the E-
EPR is described with the use of a service-oriented approach that utilizes
web services and BPEL on a cloud computing platform. For the E-EPR
implementation Amazon cloud is suggested and used as a leader company on
cloud computing that provides a full set of secured cloud services for
IaaS, PaaS and SaaS. This way a scalable system was developed and the TCO
and the overhead of IT management are decreased for the participating
organizations [6,15,18]. As concerns security, the security features of
Amazon cloud services were used and security servers were deployed locally
at ambulance service and hospital emergency departments and on cloud
infrastructure to provide role and context-based authorization services.
Currently, the domain context information is not organized into domain
ontology. The proposed E-EPR architecture is indented to be further
extended by organizing domain context information into domain ontology to
enable context sharing in a semantic way and context reasoning. In
addition, the Amazon Virtual Private Cloud (VPN) service is indented to be
used to create a secure bridge among the ambulance service, hospital
emergency departments and the Amazon cloud.


REFERENCES

1] Amazon Web Services: 2010. Overview of Security Processes, Available
from URL
http://media.amazonwebservices.com/pdf/AWS_Security_Whitepaper.pdf (last
accessed 10-12-2010).
2] Amazon Web Services: 2009. Creating HIPAA-Compliant medical data
applications with Amazon Web Services, Available from URL
http://awsmedia.s3.amazonaws.com/AWS_HIPAA_Whitepaper_Final.pdf (last
accessed 10-12-2010).
3] Buyya, B., Yeo, C., Venugopal, S., Broberg, J. and Brandic, I. 2009.
Cloud computing and emerging IT platforms: Vision, hype, and reality for
delivering computing as the 5th utility. Future Gener. Comp. Sy. 25
(2009), 599-616.
4] Cao, B., Li, B. and Xia, Q. 2009. A service-oriented Qos-Assured and
Multi-Agent cloud computing architecture. Lect. Notes Comp. Sci. 2009.
5931 (2009), 644-649.
5] Coskun, N and Erol, R. 2010. An optimization model for locating and
sizing emergency medical service stations. J. Med. Syst. 34 (2010), 43-
49.
6] Dornemann, T., Juhnke, E. and Freisleben B. 2009. On-demand resource
provisioning for BPEL workflows using Amazon's Elastic Compute Cloud. In
Proceedings of the 9th IEEE/ACM international symposium on Cluster
Computing and the Grid. CCGRID '09, Shanghai, China, 140-147.
7] Fang, Z. and Yin, C. 2010. BPM architecture design based on cloud
computing. Intel. Inform. Manage. 2 (2010), 329-333.
8] Flieder, K. 2007. Integrating the virtual world: Teaching EAI and E-
business integration at universities of applied sciences. In Proceedings
of the International Conference of "Interactive computer aided learning"
ICL2007 : E-Portofolio and Quality in e-Learning. ICL '07, Villach,
Austria.
9] Hameed, S., Hassan, A., Shabnam, S., Miho, V. and Khalifa, O. 2008. An
Efficient Emergency, Healthcare, and Medical Information System.
International Journals of Biometric and Bioinformatics. 2:5 (2008), 1-9.
10] Hirshon, J., Warner, M., Irvin, C., Niska, R., Andersen, D., Smith, G.
and Linda, F. 2009. Research Using Emergency Department–related Data
Sets: Current Status and Future Directions. Acad. Emerg. Med 16 (2009)
1103-1109.
11] Hsieh, S., Hou, I., Cheng, P., Tan, C., Shen, P., Hsu, K., Hsieh, S.
and Lai F. 2009. Design and implementation of web-based mobile electronic
medication administration record. J. Med. Syst. 34 (2009), 947–958.
12] Hsieh, S., Hsieh, S., Chien, Y., Weng, Y., Hsu, K., Chen, C., Tu, C.,
Wang, Z. and Lai F. 2010. Newborn screening healthcare information system
based on service-oriented architecture. J. Med. Syst. 34 (2010), 519–530.
13] Hung, Le X., Lee, S., Lee, Y., Lee, H., Khalid, M. and Sankar R. 2010.
Activity-oriented access control to ubiquitous hospital information and
services. Inform. Sciences. 180 (2010), 2979-2990.
14] Leymann, A., Mietzner, F. and Strauch, R. 2009. Towards BPEL in the
cloud: Exploiting different delivery models for the execution of business
processes. In Proceedings of IEEE Congress on Services 2009, SERVICES
'09, Los Angeles, California, USA, 670 – 677.
15] Peng, B., Cui, B. and Li, X. 2009. Implementation issues of a cloud
computing platform. In Proceedings of the IEEE Data Engineering. ICDE
'09, Shanghai, China, 32:1.
16] Poulymenopoulou, M., Malamateniou, F. and Vassilacopoulos G. 2003.
Emergency healthcare process automation using workflow technology and web
services. Med. Inform. & Intern in Med. 28:3 (2003), 195-207.








17] Poulymenopoulou, M. and Vassilacopoulos, G. 2004. An electronic patient
record implementation using clinical document architecture. In
Proceedings of International Council on Medical and Care Compunetics.
ICMCC '04, Hague, Netherlands, 103, 50-57.
18] Rodero-Merino, L., Vaquero, L., Gilb, V., Galan, F., Fontan, J.,
Montero, R. and Llorente, I. 2010. From infrastructure delivery to
service management in clouds. Future Gener. Comp. Syv. 26:8 (2010).
19] Rosenthal, A., Mork, P., Li, M., Stanford, J., Koester, D. and
Reynolds, P. 2010. Cloud computing: A new business paradigm for
biomedical information sharing. J. Biomed. Inform. 43 (2010), 342–353.
20] Suriarachchi, A. 2010. Auto scaling web services on Amazon EC2,
Available from URL http://wso2.org/library/articles/auto-scaling-web-
services-amazon-ec2 (last accessed 10-12-2010)
21] Turkmen, F. and Crispo, B. 2008. Performance evaluation of XACML PDP
implementations. In Proceedings of the 2008 ACM workshop on Secure web
services. CCS '08, Alexandria, USA, 37-44.
22] Varia, J. 2010. Cloud architectures, White Paper of Amazon Web
Services, Available from URL
http://jineshvaria.s3.amazonaws.com/public/cloudarchitectures-varia.pdf
(last accessed 10-12-2010).
23] Wagener, J., Spjuth, O., Willighagen, E. and Wikberg, J. 2009. XMPP for
cloud computing in bioinformatics supporting discovery and invocation of
asynchronous web services. BMC Bioinformatics. 10 (2009), 279.
24] Wilamuna, C. 2010. Getting Started with WSO2 Cloud Virtual Machines for
Amazon EC2, Available from URL http://wso2.org/library/articles/getting-
started-wso2-cloud-virtual-machines-amazon-ec2 (last accessed 10-12-
2010).
25] Wu, Z., Chung, Y., Lai, F. and Chen T. 2010. A password-based user
authentication scheme for the integrated EPR information system. J. Med.
Syst. Published Online (2010).
26] Yang, T., Sun, Y. and Lai F. 2009. A scalable healthcare information
system based on a service-oriented architecture. J. Med. Syst. Published
Online (2009).
27] Zhang, R. and Liu L. 2010. Security models and requirements for
healthcare application clouds. In Proceedings of 3rd International
Conference on Cloud Computing 2010. IEEE Cloud '10, Miami, Florida, USA,
268-275.
28] Zhou, Y., Liu, X, Wang, X., Xue, L., Liang, X. and Liang S. 2010.
Business process centric Platform-as-a-Service model and technologies for
cloud enabled industry solutions. In Proceedings of the 3rd International
Conference on Cloud Computing 2010. IEEE Cloud '10, Miami, Florida, USA,
534-537.

-----------------------
Cloud Infrastructure



IaaS (Amazon EC2, Amazon S3)



PaaS (Amazon SQS)



SaaS (E-EPR as a service)



BPaaS



Server Nodes



Hospital/Ambulance Service



Existing Information System



Database Servers



Local Security

Server



Amazon Cloud



Elastic Compute Cloud (EC2)



Machine Images



On-demand Instances



Database Server



Business Process Server



Application Server



Global Security

Server



Amazon S3



Amazon SQS



Internet