EXPLOITING SERVICE ORIENTED ARCHITECTURES FOR

THE DESIGN OF E-HEALTH SYSTEMS

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.

1 INTRODUCTION

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

219

Da Silveira M. and Guelﬁ N. (2008).

EXPLOITING SERVICE ORIENTED ARCHITECTURES FOR THE DESIGN OF E-HEALTH SYSTEMS.

In Proceedings of the First International Conference on Health Informatics, pages 219-224

 SciTePress

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

organizations.

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

project.

2 IDENTIFYING PROBLEMS IN

HEALTHCARE SYSTEMS

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

220

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

implemented.

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

systems.

3 SERVICE ORIENTED

ARCHITECTURE

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

Independence)

 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

Independence)

 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.

EXPLOITING SERVICE ORIENTED ARCHITECTURES FOR THE DESIGN OF E-HEALTH SYSTEMS

221

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

functionality.

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

domain.

HEALTHINF 2008 - International Conference on Health Informatics

222

4 EXPLOITING SOA IN

E-HEALTH SYSTEMS

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.

5 DISCUSSION AND

CONCLUSIONS

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

EXPLOITING SERVICE ORIENTED ARCHITECTURES FOR THE DESIGN OF E-HEALTH SYSTEMS

223

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

administration.

REFERENCES

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

http://www.centc251.org/

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

http://medical.nema.org/dicom/2003/03_01PU.PDF

Eysenbach G.: What is e-health? Journal of Medical

Internet Research, Apr–Jun, 2001, Vol. 3, Issue 2:

e20.

Garner C. A.: Offshoring in service sector: Economic

impacts and policy issues. Online paper, 2004.

Website of Kansas City Bank.

http://www.kansascityfed.org/Publicat/Econrev/PDF/3

Q04Garn.pdf

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

http://www.gao.gov/new.items/d05628.pdf

Gupta S.: Service Oriented Architecture - Part 2. Java

Boutique. Retrieved June 10, 2007, from

http://javaboutique.internet.com/tutorials/serv_orient/i

ndex-4.html

Health Level Seven. Retrieved June 10, 2007, from

http://www.hl7.org/

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

http://www.snomed.org/snomedct/standards.html

TAPAS. Retrieved June 10, 2007, from

http://tapas.item.ntnu.no/wiki/index.php/Main_Page

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

224