Marcos Da Silveira and Nicolas Guelfi
Laboratory for Advanced Software Systems, University of Luxembourg, 6, rue Coudenhove-Kalergi, L-1359 Luxembourg
Keywords: Service oriented architecture, interoperability, standards, e-health, information technology.
Abstract: The design of e-Health systems is a hard task since their requirements are complex and heterogeneous.
These systems merge functional requirements with an important set of non–functional requirement like
security, safety, standardization or technology related constraints concerning the hardware and software
components to be used. The ICT research community has proposed recently architectural models for the
development of open and dynamic distributed systems centered on the concept of “service”. This approach
has been followed by all the major actors of ICT for their frameworks due to its adaptation to the World-
Wide-Web. This paper is a position paper where we analyze the current status and needs for e-Health
systems and the limitation upon them. We present the main characteristics of middlewares that follow a
service-oriented architecture and we explain how these frameworks could be exploited, as a vision to the
future, to design e-health systems for a better insurance of their functional and non-functional requirements.
Healthcare market is a typical example of service
sector that has successfully increased its
participation in the world’s economy. Because of the
importance of services market, in particular business
and healthcare services, their development and their
delivering have become the center of discussion in
many levels of the society. Politicians and lowers
have looking for adapted legislations and controls
(Garner, 2004). Educators and industries search
convenient methods to introduce service science
(Chesbrough & Spohrer, 2006) into the continue
education and to use it to prepare a new generation
of healthcare professionals. A generation that needs
interdisciplinary knowledge to increase the
productivity and innovation of service delivering.
In a digital society, the concept of services
evolves and words like e-service and web-service
gains their place in the market. In health domain,
these new kind of services have facing many
difficulties (resistance to change habitudes,
misinformation, technological phobias, etc.).
However, caregivers are slowly getting used with
the idea of adopting informatics devices to improve
the quality of their services. Some countries are
catalyzing this process forcing caregivers to use
Information and Communication Technologies
(ICT) to interact with public administrators (for
example, social security administration and public
hospitals administrations) (Currie & Guah,
2006),(GAO, 2005).
Clearly, the association of informatics with
healthcare domains brings up many advantages.
Healthcare industry is positioned to beneficiate of
the advancements in technology and connectivity.
High technological devices and software are
available for healthcare services’ providers and are
adapted to the patient needs (patient-centered
systems). Customers of these technologies can
expect to achieve greater performance, reduce costs
and improve patient care. Consequently, they are
expanding marketshare and are pushing the
transition to a digital era of e-Health. In this paper,
the word e-Health expresses the association of e-
technologies with healthcare services. Similar words
have been used in the literature to express the
association of specific informatics technology with
healthcare, as well as telecare, telemedicine,
telehealth, bioinformatics, etc. (Norris, 2002). The
definition that we consider the most appropriated to
our work was proposed by (Eysenbach, 2001).
“e-Health is an emerging field in the
intersection of medical informatics, public health
and business, referring to health services and
information delivered or enhanced through the
Internet and related technologies. In a broader
sense, the term characterizes not only a technical
Da Silveira M. and Guelfi N. (2008).
In Proceedings of the First International Conference on Health Informatics, pages 219-224
development, but also a state-of-mind, a way of
thinking, an attitude, and a commitment for
networked, global thinking, to improve health care
locally, regionally, and worldwide by using
information and communication technology”
The complexity associated with the design of e-
Health systems and its application environment has
driven developers to look for methodologies that can
simplify their work. The service-oriented
architecture (SOA) is a solution that is captivating
many important industrials. SOA describes the
practices and frameworks that enable the
functionality and information of applications to be
provided and consumed as service interfaces. In this
formalism, services can be seen as network
addressable entities with a well-defined, easy-to-use
and standardized interface. From a technical
viewpoint, SOA is essentially a collection of
software services communicating with each other
over a network to pass data or to coordinate
activities. The software services can be implemented
as gray boxes where implementation details (as well
as the technologies used) are not necessarily
accessible by the clients. The main expected benefit
of SOA is their capacity of satisfying the
requirements of complex and heterogeneous
information systems domains such as healthcare.
Further, services can be combined in different ways
to support the evolution of processes and
organizational models, for example towards virtual
The work developed at LASSY (Laboratory for
Advanced Software Systems) aims to contribute to
the improvement of the organizational structure of
health systems proposing a SOA adapted to e-Health
requirements. In this paper we identify the current
status and needs for e-Health systems and the
limitations upon them. Section 2 introduces some
problems observed in the Healthcare structure.
Section 3 presents the mains concepts of service
oriented architecture (SOA) and a summary of
TAPAS project. Section 4 describes the potential
application of SOA for designing e-Health systems
as the objectives and perspectives of RESIST
The current situation of healthcare domain points to
an excessive individualization of activities and a
lack of communication inside of the institutions.
Information generated to/by one caregiver is rarely
shared and finishes in an archive (electronic records
or not) often inaccessible by other caregivers and by
the patient. The same problem had been faced in
other professional activities, the most representative
are the financial activities. Continuous investments
on ICT solutions contribute to reduce the
consequences of this problem. (Luftman et al., 1993)
highlights that the effective and efficient utilization
of information technology requires the alignment of
IT strategies with the business ones, what was not
successfully done in the past with traditional
approaches. The same idea can be applied in
healthcare systems waiting for attaining efficient and
responsible use of ICT to solve the exigencies of
healthcare centers’ administrators, caregivers,
patients and governments. This idea is not
completely new, some hospitals use ICT in their
organization from the lasts 25 years. But this
initiatives are rare and do not represent the majority
of the cases. According to the Department of Health
and Human Service of USA (HHS), healthcare is the
largest sector of the economy that has not fully
embraced information technology. The Medical
Group Management Association reported that only
31% of physician group practices use fully
operational Electronic Health Records (EHRs). The
Healthcare Information and Management Systems
Society reported that 19% of hospitals use fully
operational EHRs (GAO, 2005). The results of these
initiatives were reported in (Currie & Guah, 2006),
(Wears et al., 2006), (Keizer & Ammenwerth,
2007), but we are only at the beginning of great
changes produced by the association of information
technologies, network managed organizations and
specialization with the healthcare domain. The
current challenge is to define how to integrate the set
of existing specific solutions?
Many solutions use proprietary data exchange
format and do not interact with the others.
Interoperability becomes now fundamental to
healthcare communities. Industries, research groups
and governments are investing time and money to
solve this problem. Many standards are emerging of
these collaborations, but few of them are currently
integrated in most commercial systems (HL7, 2007),
(CEN, 2006), (DICOM, 2003). Unclear legislation,
lucrative market, implementation costs, physicians’
reluctance and disorganization contribute to prolong
that reality. The way that IT solutions have been
implemented in healthcare systems are not exactly
what users expect and it will not solve all problems
in this domain, but it is a beginning to improve the
healthcare services’ quality. The benefits that can be
expected are:
For the consumer: Higher quality care;
Reduction in medical errors; Fewer duplicate
treatments and tests; Decrease in paperwork;
Lower healthcare costs; Constant access to
HEALTHINF 2008 - International Conference on Health Informatics
health information; Expansion of access to
affordable care;
For the public health sector: Early detection of
infectious disease outbreaks around the
country; Improved tracking of chronic disease
management; Ability to gather de-identified
data for research purposes; Evaluation of
health care based on value, enabled by the
collection of price and quality information that
can be compared.
All these benefits contribute to improve the life
quality of patients, but our main motivation is in
reducing (or eliminating, if possible) the alarming
number of deaths related to medical error that could
be prevented if an efficient IT system was
The implementation of a good IT requires the
selection of an architecture that can represent as real
as possible the way of working of stakeholder in
healthcare domain. The next section presents the
main characteristics of the architecture that we
consider as the most appropriated to e-Health
The concept of service-oriented architecture is not
new, but with the advent of recent platform-
independent programs and platform-neutral data
models, this architecture took more attention. A
unique formal definition of SOA does not exist, and
discussion about it is out of the scope of this paper.
However, we can highlight some important aspects
(Gupta, 2007):
The service-consumer needs must be specified
independently of the service-provider
component. A reasoning engine takes the
responsibility of aligning the two
specifications. This engine, often named
Assembler component, bridges the gap
between the two end-elements (consumer and
provider). (Loose Coupling)
The technology used by the service-consumer is
completely independent of the one used by the
service-provider and vice-versa. (Platform
The communication between the two end-
elements must not be dependent of the
protocol. A variety of communication protocol
must be available to request/offer a Service.
The choice of protocol must not modify the
quality of the service. Binding to a specific
protocol must take place at run-
time/deployment-time, and not at the design or
development time. (Communication Protocol
Each of the provider- and consumer-service
components should be able to be implemented
in their own time, according to their own life-
cycle. (Life-cycle Independence)
Specially designed for flexibility and reuse, a
SOA enables organizations to easily integrate
systems, data, applications, and processes through
the linking of services. SOA was first proposed to
satisfy the necessities of business design and
implementation that was not supplied by distributed-
oriented architecture (DOA, e.g. CORBA, J2EE,
etc.). It can be used as a complementary platform or
to substitute DOA for providing intra and inter-
business services. The general concept of SOA is
close of the one of DOA, however there are small
differences and the sum of these features leads to a
radically different set of properties for enterprise-
level system modeling and design (Baker &
Dobson, 2005). SOA is a software architecture that
uses loosely coupled software services to support
the requirements of business processes and software
users. It is technology neutral and has no standard
specification of the components interface, what
offers dynamism and flexibility to the system. The
utilization of asynchronous message exchange
instead of function calls allows services to be
executed without share details about its
implementation or platform. SOA enables
uncomplicated connectivity by abstracting
dependencies away from each application into an e-
service (or other brokering service, e.g. web-
service). Applications can then easily be connected
to the broker through modular components. And
each application can be modified whenever
necessary to support flexible and dynamic business
processes through platform-independent.
The design and development of a SOA implies a
different way of organizing the system. Designers
must to change the component oriented vision and
think about services’ “properties and attributes”. It
requires the application of a number of techniques
stemming from disciplines such as Enterprise
Architecture, Business Process Modeling,
Component-based development and Object-oriented
methods – to produce modular, reusable and
replaceable software applications.
It seems to be more complicated then DOA. In
fact, it demands an extra effort on coordination and
interface definition to understand information assets
and link to business process. However, once created
the basic structure, modifications in a service does
not request the understanding of the whole model.
Figure 1: TAPAS basic architecture.
Services can be seen as gray boxes that have a
description file each one (normally in XML) which
specifies the interface and some other attributes of
the service. Further, most gray boxes in a SOA are
represented as legacy applications. However these
will usually need re-engineering to provide access to
their functionality and data from a wider population
of consumers. The key of a good SOA
implementation depends on the specification of the
services’ interface and the reasoning engine to mach
requested services with offered ones. An usual way
to solve this problem is to implement different layers
of functionalities that see the services with different
granularity. The approach described in TAPAS
project (TAPAS, 2007), for example, proposes three
layers: Service, Play and Network. The service layer
consists of service components definition and the
network layer consists of nodes specification (places
where services can be executed). The play layer is
used to connect consumers with providers and to
identify the node to execute the service.
The next section presents more details about
TAPAS’ concepts, but a complete information about
this approach can be found in the project website
(TAPAS, 2007).
3.1 TAPAS’ Main Concepts
The TAPAS project is a research project developed
at NTNU which aims at developing and
architecturing for network-based service systems
with: a) flexibility and adaptability; b) robustness
and survivability; and c) QoS awareness and
resource control. The goal is to enhance the
flexibility, efficiency and simplicity of system
installation, deployment, operation, management and
maintenance by enabling dynamic configuration of
network components and network-based service
The TAPAS basic architecture, illustrated in
Figure 1, is founded on generic Actors (software
components) and on the Nodes of the network. The
actors play Roles defined in a Manuscript, which
consists of an EFSM (Extended Finite State
Machine) extended with rule-based policies. The
nodes may be servers, routers, switches, and user
terminals, such as telephones, laptops, PCs, PDAs,
etc. The idea is to associate the design model to a
theatre organization. The Actors are coordinated by
Director that also represents a Domain. Service
System consists of a set of Service Components,
which are units related to some well-defined
functionality defined by a Play. A Play represents
several Actors playing different Roles. The ability of
Actors to play Roles depends on the defined
required Capability and the matching offered
Capability in a Node where they intend to execute.
Capability is an inherent property of a Node or
user, it may be resources (e.g. CPU, hard disk,
transmission channels), functions (e.g. printing,
encryption devices), or data (e.g. user login, access
rights) (Lühr, 2004). Where and how Actors are
installed and roles executed are decided by the
Configuration Manager. It is responsible for
obtaining a snapshot of all system resources, and
taking decisions about the configuration. This brief
introduction to TAPAS gives an idea of the
potentiality of this approach. The next section
explains how TAPAS can be applied into healthcare
HEALTHINF 2008 - International Conference on Health Informatics
Analyzing the weaknesses of healthcare systems’
organization described in section 2 and the features
that can be expected from SOA, we can imagine that
SOA is an interesting approach to supply many
identified problems of health sector. In this
architecture we can identify services associated with
the specification: of different classes of users; of
polices to increase the security and the reliability; of
interfaces to allow communication between
applications and between systems; of common
terminologies to facilitate information exchange and
information understanding; etc.
Composed of a set of (reusable) services, this
structure facilitates the management of the offered
services and allows to measure more accurately the
quality of those services (QoS). Improvement of
QoS is an important requirement of e-health
systems. Thus, in this structure the patients that can
input data to accurate the QoS (having a proactive
role) and consequently trust more on the (managers)
selection of actors for the required services
according to the level of QoS specified (feedback).
Further, the healthcare administration centers can
obtain all (or much more than today) necessary
information to take decisions about the service. In a
sense, the services-providers (caregivers,
equipments and software’s providers, pharmacies,
etc.) are pushed to improve their QoS in order to
keep their marketshare.
Following this trends, TAPAS proposes to create
a plug-and-play environment where services and
users can be dynamically included/logged on,
excluded/logged off or modified (moving, changing
of resources, changing the quality of services, etc.)
without a big effort. Initially developed to general
propositions, the current version of TAPAS is not
completely adapted to healthcare systems. The
conception and implementation of a TAPAS top
level to include specific properties of healthcare
sector is one of the objectives of RESIST research
project, in development at University of
Luxembourg, LASSY (Laboratory for Advanced
Software SYstems) workgroup.
Evaluating TAPAS properties we highlight the
well defined distributed management structure,
separating the operational specification from the
management specification. Where decisions are
distributed and decision-makers can have different
priorities and criteria. These elements together with
the user-friendly description of the operational
architecture (theatre metaphor) facilitate the
complex definition of the architecture lifecycle of a
healthcare organization. In other words, TAPAS
assists the design and implementation of the
following tasks: modeling, service composition,
deployment and execution management.
TAPAS is structured clearly and formally. The
description of the Role by means of Manuscripts in
XML files follows the international trends to
improve the syntactic interoperability and
standardize business interface. RESIST project plan
to use this facilities to benefit from ontological
standards (SNOMED, 2007), when described in
XML. The rule-based reasoning engine proposed
into this architecture is an intelligent solution to
associate dynamically services requests with
services providers and to guarantee that the specified
quality threshold will be respected if there is an
actor that can satisfy it. In the specification of
TAPAS we can observe that the authors also
introduce tools to detect, diagnosis and recovering
faults. These tools are in development, but it can
become an interesting alternative to improve
security, reliability and availability properties. This
is an innovation that we can not be found in
commercial tools whose base their security only on
the communication/data access security policies.
If the gap between public knowledge and academic
curriculum isn't large enough, the gap between
academia and professional practice is a gaping hole.
While academic departments insists on doctor-
centered teachings in an ideal organizational
environment, medical industries have innovating
proposing adapted solutions to specialized needs.
Some existing medical equipments can be easily
manipulate by ten-year-old boys and can give
precise information about the health state of the
patient. This is one of the contributions of e-Health.
Moving away from classical methods to focus on
delivering quality services that are in-line with the
new context of modern medicine is the challenge of
the next decades. Informatics came to give support
to it in order by proposing tools to mange, integrate,
disseminate and generate health information.
Proving its worth in different business domain,
ICT solutions have been implemented on many
hospitals, leading to reduce medical errors and to
improve the quality of medical services. But the
complexity of managing all needs of stakeholders in
health domain had carried out many difficulties on
e-Health implementations.
The solution proposed in this paper is the
designing and implementation of e-Health systems
based on SOA definitions. We remind that in this
architecture, core business capabilities are
encapsulated within independent software services,
and these services are leveraged by various front-end
applications to fulfill business requirements. The
main properties of this approach are the use of
business-oriented services; message-based
interactions with “gray box” implementations;
communication over a network; platform neutrality;
service description and discovery; and loose
coupling between system components (Kawamoto &
Lobach, 2007). This set of properties leads to a
simpler approach to software design and
implementation and to enhancing re-use of existing
IT resources. What gives to the system the ability to
adapt to changing business requirements in a
flexible, agile manner; and the potential for
significant cost saving.
Lessons learned from countries’ pioneer for the
e-Health implementation shows that interoperability
is a critical and crucial aspect for any national (and
international) program. Many researches are
contributing to develop it, but data exchange
between softwares and between systems (respecting
international directive for data control) still is a big
challenge. These lessons had been taken into
account during the development of RESIST project.
The key idea is to improve the life quality of patients
in Luxembourg, proposing a dynamic, flexible and
standardized infrastructure to integrate healthcare
application. The Plug-and-Play middleware
developed in TAPAS project seams to be a good
option to reach the RESIST aims. Our contribution
in short term is the specification of an architectural
framework to cover the stakeholders’ necessities and
the implementation of a top level in TAPAS
middleware to adapt it to healthcare applications’
needs. A case study has been specified to implement
home monitoring in cardiology’s departments.
Current works targeting the identification of the
requirements to create a Luxembourgish e-health
environment. It deals with patient interests,
caregivers’ capabilities, healthcare centers’
managements and governmental regulations and
Baker S.; Dobson S.: Comparing service-oriented and
distributed object architectures. In (Robert Meersman
and Zahir Tari et al, editors): Proceedings of the
International Symposium on Distributed Objects and
Applications, LNCS. Springer Verlag, 2005.
CEN/TC 251: European Standardization of Health
Informatics, 2006. Retrieved June 10, 2007, from
Currie W. L.; Guah M. W.: IT-enabled healthcare
delivery: The U.K. National Health Service.
Information Systems Management, 2006, Vol. 23,
Issue 2, pages 7-22.
Chesbrough H.; Spohrer J.: A research manifesto for
services science. Communications of the ACM, July,
2006, Vol. 49, Issue 7, pages 35-40.
DICOM: Part 1: Introduction and Overview. Retrieved
June 10, 2007, from
Eysenbach G.: What is e-health? Journal of Medical
Internet Research, Apr–Jun, 2001, Vol. 3, Issue 2:
Garner C. A.: Offshoring in service sector: Economic
impacts and policy issues. Online paper, 2004.
Website of Kansas City Bank.
GAO - United States Government Accountability Office:
Health information technology: HHS is taking steps to
develop a national strategy. Report to the Chairman,
Committee on the Budget, House of Representatives,
May, 2005. Retrieved June 10, 2007, from
Gupta S.: Service Oriented Architecture - Part 2. Java
Boutique. Retrieved June 10, 2007, from
Health Level Seven. Retrieved June 10, 2007, from
De Keizer N. F.; Ammenwerth E.: The quality of
evidence in health informatics: How did the quality of
healthcare IT evaluation publications develop from
1982 to 2005?. International Journal of Medical
Informatics, in press, 2007.
Kawamoto K, Lobach D.: Proposal for Fulfilling Strategic
Objectives of the U.S. Roadmap for National Action
on Decision Support through a Service-Oriented
Architecture Leveraging HL7 Services. Journal of the
American Medical Informatics Association, 2007, Vol.
14, pages 146 –155.
Luftman J. N., Lewis P. R., Oldach S. H.: Transforming
the enterprise: The alignment of business and
information technology strategies. IBM Systems
Journal, 1993, Vol. 32, Issue 1, pages 198 – 221.
Lühr E.: Mobility support for wireless devices - within the
TAPAS platform. Master thesis at Norwegian
University of Science and Technology – NTNU, 2004.
Norris, A.C.: Essentials of telemedicine and telecare. John
Wiley&Sons, 2002
Systematized Nomenclature of Medicine for Clinical
Terms, SNOMED-CT international release 2007.
Retrieved June 10, 2007, from
TAPAS. Retrieved June 10, 2007, from
Wears R. L.; Cook R. I.; Perry S. J.: Automation,
interaction, complexity, and failure: A case study.
Reliability Engineering and System Safety, 2006, Vol.
91, pages 1494–1501
HEALTHINF 2008 - International Conference on Health Informatics