ENHANCING CONTEXT ANALYSIS WITH INTELLIGENCE IN

PROVIDING e-HEALTH SERVICES

Less Infrastructure Dependency in Supporting Cardio-Vascular Patients

Boris Shishkov

IICREST / Department of Systems Engineering, TU Delft, Jaffalaan 5, Delft, The Netherlands

Alexander Verbraeck

Department of Systems Engineering, TU Delft, Jaffalaan 5, Delft, The Netherlands

Ing Widya

Department of Computer Science, University of Twente, Drienerlolaan 5, Enschede, The Netherlands

Keywords: Context-aware applications, Software components, e-Health services, Intelligent patient support.

Abstract: In Europe, we observe an increasing number of people with health problems, who could theoretically

receive care outside of a hospital when their condition could be properly monitored. Not being able to

provide this monitoring leads to an increasing pressure on an already overcrowded hospital system and

increased costs. Ubiquitous technology on top of a high-quality IT infra-structure has already proven to be

able to provide partial solutions. However, such infrastructure is not available throughout Europe. This

brings the challenge of finding cheap, adaptive, and less infrastructure-dependent technological solutions. In

the current paper we propose some solution ideas concerning the mentioned problems, which ideas are

rooted in context analysis. In particular, we take context into account because adequately adapting the

delivered services to the situation of the patient could result in more effective support. We incorporate

multi-level context states and distinguish between some perspectives on context states for the design of

flexible and adaptive ICT applications. The IT system autonomously considers context not only for the

patient but also for the other related stakeholders such as caregivers. We illustrate our ideas with an example

concerning cardio-vascular patients and expect the solutions to be extendable to other health care domains.

The results can be generalized to also derive more fundamental knowledge on the possible ways in which

context-aware solutions can be applied.

1 INTRODUCTION

In Europe, we observe an increasing number of

people with health problems, who could

theoretically receive care outside of a hospital when

their condition could be properly monitored. Not

being able to provide this monitoring leads to an

increasing pressure on an already overcrowded

hospital system and increased costs.

Ubiquitous technology on top of a high-quality

IT infrastructure has already proven to be able to

provide partial solutions. Tele-monitoring has been

researched for years and the achieved results are

more impressive than just hearing the heartbeat of a

patient in Australia from The Netherlands, for

example. There are more advanced things that could

be done, such as the monitoring of epileptic patients

at home and offering them immediate help when

needed (A-MUSE Project, 2008), to mention just an

example. These examples point, nevertheless, to

multidisciplinary challenges, as they involve

medical, logistical, and ICT issues. We approach the

development of ICT applications from this

multidisciplinary perspective, analyzing achieved

results and proposing new solutions. A starting point

we consider is appropriately analyzing context in

414

Shishkov B., Verbraeck A. and Widya I. (2009).

ENHANCING CONTEXT ANALYSIS WITH INTELLIGENCE IN PROVIDING e-HEALTH SERVICES - Less Infrastructure Dependency in Supporting

Cardio-Vascular Patients.

In Proceedings of the 4th International Conference on Software and Data Technologies, pages 414-420

DOI: 10.5220/0002314004140420

 SciTePress

developing applications and this concerns context

modeling abstractions and a context handling

platform. The context modeling abstractions provide

application developers with proper conceptual

foundations that can be extended and specialized

with specific application requirements. The context

handling platform allows some application

functionality to be delegated to the platform, which

reduces application development effort, time and,

therefore, costs.

Until recently, computation was limited to an

interaction style in which users provide to a desktop

computer all the required input to perform particular

tasks. Nowadays, computation is evolving to an

interaction style in which explicit user intervention

is gradually less required (Shishkov & Van

Sinderen, 2008). Explicit user inputs are being

progressively replaced by conditions detected by

sensors, devices and computers distributed in the

environment. Hence, technological advances support

(or enable) the shift of computing from the desktop

paradigm into a paradigm in which computing is

immersed in the dynamic world where we live and

act (Moran & Dourish, 2001). This paradigm shift

poses many challenges, mainly related to whom,

how, when and where to deliver services in the

myriad of situations that can be encountered in the

real world, which is the ever-changing context of

use. In this view, capturing and monitoring the

context in which services should be delivered, and

adapting services according to the context and user

preferences are essentially needed.

The underlying goal considered in this paper is

finding cheap, adaptive, and less infrastructure-

dependent technological solutions in the above-

discussed perspective. We propose solution

directions concerning these problems, which are

rooted in context analysis. In particular, we take

context into account because adequately adapting

the delivered services to the situation of the patient

could result in more effective support. We

incorporate multi-level context states and distinguish

between some perspectives on context states for the

design of flexible and adaptive ICT applications.

The IT system autonomously considers context not

only for the patient but also for the other related

stakeholders. We illustrate our ideas with an

example concerning cardio-vascular patients and

expect the solutions to be extendable to other health

care domains. The results can be generalized to also

derive more fundamental knowledge on the possible

ways in which context-aware solutions can be

applied.

With respect to the issue of providing support to

cardio-vascular patients, it is to be noted that

solutions to support the monitoring and help in case

of emergency of patients require big investments and

good IT infrastructure, which is often not the case in

more isolated European countries, such as Bulgaria

and Romania, while at the same time the severity of

cardio-vascular problems is high there also. In these

countries, some people with heart problems (often

elderly people) who sometimes have nobody to take

care of them, and who often suffer from lung and

other problems (for instance, Chronic Obstructive

Pulmonary Disease - COPD) at the same time, can

rely on very limited support from the state, which

makes it unrealistic to expect to apply advanced

technology in the same way in which this is done in

countries, such as Switzerland and The Netherlands.

Therefore, innovative solutions building on a robust

IT architecture are needed. For these particular

problems, the use of context awareness is expected

to provide the basis for a multidisciplinary solution.

The outline of this paper is as follows: Section 2

is furthering the discussion on context-awareness,

including a detailed analysis and presenting our

proposed views. Section 3 contains the running

example that will be reflected in Section 4 in which

we will partially illustrate our proposed views,

elaborate more on our solution directions, and

generalize the results accomplished. Finally, Section

5 contains the conclusions.

2 ENHANCING CONTEXT

ANALYSIS

Context-aware applications are (in tune with the

discussion so far) primarily motivated by their

potential to increase user-perceived effectiveness,

i.e. to provide services that better suit the needs of

the end-user, by taking into account the user

situation (Shishkov & Van Sinderen, 2008). We

refer to the collection of parameters that determine

the situation of an end-user, and which are relevant

for the application in pursue of user-perceived

effectiveness, as end-user context, or context for

short (as according to literature (Shishkov et al.,

2008)). Context-awareness implies that information

on the end-user context must be captured, preferably

without conscious or active involvement of the end-

user. Although in principle the end-user could also

provide context information by directly interacting

with the application, one can assume that in practice

this would be too cumbersome if not impossible; it

ENHANCING CONTEXT ANALYSIS WITH INTELLIGENCE IN PROVIDING e-HEALTH SERVICES - Less

Infrastructure Dependency in Supporting Cardio-Vascular Patients

415

would require deep expertise to know the relevant

context parameters and how these are correctly

defined, and furthermore be very time consuming

and error-prone to provide the parameter

specifications as manual input. In case of health

applications, context information is needed when

end-users are least likely to be able to provide the

input themselves. For these applications, it is even

more important that the applications gather the

context information independently of the end-user

providing manual input. Context-aware applications

can be particularly effective if the end-user is mobile

and uses a personal handheld device for the delivery

of services. The mobile case is characterized by

dynamic context situations often dominated by

changing location (however not necessarily

restricted to this). Different locations may imply

different social environments and different network

access options, which offer opportunities for the

provision of adaptive or value-added services based

on context sensitivity. Especially in the mobile case,

context changes are continuous, and a context-aware

application may exploit this by providing near real-

time context-based adaptation during a service

delivery session with its end-user. The adaptation is

‘near real-time’ because context information is an

approximation (not exact representation) of the real-

life context and thus there may be a time delay.

Through context-awareness, applications can be pro-

active with respect to service delivery, in addition to

being just re-active, by detecting certain context

situations that require or invite the delivery of useful

services which are then initiated by the application

instead of by a end-user request. Otherwise said,

traditional applications provide service in reaction to

user requests (re-active), whereas context-aware

applications have also the possibility of initiating a

service when a particular context situation is

detected, without end-user input (pro-active).

Although context-aware applications have received

much attention within the research community, they

have not been fully successful so far from a business

point of view. This situation may change rapidly

however, due to the observed growing power and

reduced prices of mobile devices, sensors, and

wireless networks, and due to the introduction of

new marketing strategies and service delivery

models (A-MUSE Project, 2008; Mei et al, 2007).

A context-aware application is (usually)

expected to have the ability of adapting its service

delivery depending on the information about the

user’s state (which information the application

certainly must have received); this is illustrated in

Figure 1.

As mentioned before, we are proposing a

solution to some health-monitoring-related

problems, which is rooted in context analysis. In

Figure 1: Schematic representation of a context-aware

application (Shishkov & Van Sinderen, 2008).

particular, we take context into account because

adequately adapting the delivered services to the

situation of the patient would result in more

effective support. We incorporate multi-level

context states and distinguish between different

perspectives on context states for the design of

flexible and adaptive ICT applications. The IT

system autonomously considers context not only for

the patient but also for the other related stakeholders.

We address hence these two innovative

proposals, namely concerning: (i) multi-level

context states and (ii) different perspectives on

context states, in the remaining part of this section.

2.1 Multi-level Context States

In previous research (Shishkov et al, 2008; Shishkov

& Van Sinderen, 2008; A-MUSE Project, 2008), we

have explored to some extent the possibilities to

enforce context driven application adaptability,

taking into account the situation of the end-user.

What has not been exhaustively addressed

nevertheless is how we take also into account the

situations of other related entities. This we focus in

the current paper. In particular, we suggest

innovative ways of modeling context situations at

different levels and we as well relate this to the

mentioned already achieved results.

These different levels are needed because it is

often not only the end-user whose situation is

relevant. Taking for example the situation in which a

patient is receiving support from a distance. We

would often face the problem of considering other

related entities as well – if the sensed vital signs of

the patient indicate possible problems, it might be

needed to provide careful analysis of a doctor,

preferable the patient’s own doctor, and if the

situation gets worse, to send an ambulance to the

patient. It has to be taken into account what the

ACT4SOC-EHST 2009 - 4th International Conference on Software and Data Technologies

416

context situation of the doctor and the ambulance is.

Maybe the ambulance of the local service point is in

a traffic jam and it would be necessary to find

another ambulance. It may be that the medical

doctors in the emergency department of the hospital

to which the patient is to be sent are busy with

another emergency case and it would be wise

sending the patient to another hospital in the area.

Concluding, it can be stated that better care could be

provided when a rich set of state information would

be available, and could be combined appropriately

for the particular case of the patient.

application

UCS

…

ECS

…

ECS

…

...

Figure 2: Considering many inter-dependent context

situations.

Hence, we have (as Figure 2 suggests) a number

of User Context States – UCS, based on which states

the application should adapt its behavior, and each

of these states points to a number of states of

relevant entities.

We might like to further our previous work that

puts all in a simpler setting where we abstract from

the context situations of all other entities (ECS)

which situations would be relevant to the desirable

application service delivery.

2.2 Different Perspectives on Context

States

Monitoring of patients remotely, especially for

disease management or supervision of elderly

persons with systemic diseases, is often a multi-

facetted process. The current perspective of the

World Health Organization (WHO) on health is in

fact extended from a bio-psycho health model,

typically expressed in terms of body functional and

structural impairments and disabilities, to a bio-

psycho socio model, additionally expressed with

terms of person’s participation in the society (WHO,

2001). This vision on health and the current trends

for patient self-management require orchestrated

multi-level loops of monitoring and treatment

controls because of the different dynamic properties

that concern the management of the systemic

diseases and the person’s participation.

A patient suffering from a chronic cardio-

vascular disease, for example, may need continuous

monitoring of his or her heart condition. The

dynamics of the monitoring or treatment of this

patient would often depend on the selected post

diagnostic treatment protocol (Von Wright, 1963).

In case of COPD as well, there would be an

additional disease management protocol needed, and

it would be of course necessary to appropriately

align this protocol with the (primary) cardio-

vascular disease management protocol.

The ICT facilities that should support the patient

are to be configured therefore in accordance with the

different disease management dynamics. This would

involve in turn several context state trajectories,

each of which reflecting the particular disease

management protocol. Consequently, the patient

supervision processes would also require several

context state trajectories, each one in conformity

with the dynamics of the specific disease

management protocol (Moran & Dourish, 2001;

Meinert, 1986).

Besides these multiple bio-medical context state

trajectories, another context state trajectory is

needed in order to reflect the supervision of the

participation of the patient. Such supervision may

provide a better feeling of safety and availability of

on demand assistance; these often lower the

thresholds of participation. State changes of the

patient’s external environment are typically slow;

this is in contrast to emergency care or some

warning events in chronic care. Accordingly, other

control or management techniques may apply for

monitoring of patients to improve participation.

Hence, treating the discussed context state

trajectories separately, while maintaining

coordination at the same time, is believed to be a

better design practice of separation of concerns.

In the following section - Case Example, we

present a scenario that illustrates a contextual setting

for patient monitoring to improve patient’s

participation.

3 CASE EXAMPLE

As mentioned already, we will present in this section

a case example through which we will illustrate our

ideas.

ENHANCING CONTEXT ANALYSIS WITH INTELLIGENCE IN PROVIDING e-HEALTH SERVICES - Less

Infrastructure Dependency in Supporting Cardio-Vascular Patients

417

Our scenario envisions Rob Martens who is 70

years of age; he lives in a service apartment complex

for elderly. Being diagnosed as a heart patient, he

participates in a cardio-vascular monitoring program

of the local hospital’s Cardiology Department. As

many others of his age with a heart problem, Rob

also suffers from COPD. Although Rob can live on

his own, he often gets out of breath and falls if not

being able to find out a nearby place to sit.

For the monitoring program, Rob wears a

garment with dry ECG electrodes, a 3D acceleration

activity sensor with GPS and as well a PDA which

collects, processes, multiplexes and transfers Rob’s

vital signs continuously and wirelessly to the

Cardio-Care portal of the Cardiology Department. A

specialized nurse continuously occupies this portal

and a junior cardiologist is always on duty at the

department.

Being reluctant (before participating in the

monitoring program) to go out of his apartment for

socialization and even preferring to stay in his

bedroom (because of his feeling insecure), Rob feels

more secure when he knows that they continuously

monitor him and he goes down often, visiting the

common room in the complex.

On Day X, Rob goes early to the common room,

but after a few hours he feels tired and he walks

back to his apartment. In the elevator, Rob feels

dizzy and falls down. He does not manage to sit on

the bench in the elevator, neither to reach the

elevator’s alarm button. Rob’s sensory system

detects the fall however; the system is aware that he

is in the elevator and thus this is known at the

Cardio-Care portal. The portal also detects an

increase of Rob’s heart rate, it beeps for the attention

of the nurse on duty, Marit, renders Rob’s data from

his electronic patient record and switches on the

audio-visual system (display, speakers, microphone

and remotely controllable camera) in the elevator

that is usually switched off for privacy and energy

saving reasons. Via the Hi-Fi audio link Marit calms

Rob down, which effect she observes from his heart

rate reading. The trained nurse concludes from the

vital sign readings and the camera display on her

monitor that Rob’s condition is not acute and

decides therefore not to ask for an ambulance and

not to reset the elevator to go to the ground floor,

Instead, Marit clicks on her screen for a window

presenting the nurses in the vicinity of Rob

including their prioritized activity from their

electronic work schedule and their ability to assist

Rob, taking into consideration that Rob is too heavy

for many of the nurses. Marit only detect Dewi at a

floor higher and who needs a lift device to help Rob.

Marit reset the lift to go a floor higher and beeps

Dewi, who finds immediately the location of the

nearest lift device since all devices have RFD tags,

and who thus can help Rob to go back to his

apartment. In the mean time, Marit sends a report

containing the vital sign readings, the video clip and

the symptoms to John, a Cardio-Care nurse

practitioner who is assigned to Rob.

In the following section, we will further

elaborate our ideas, reflecting them in the partial

application of this case scenario.

4 SUPPORTING

CARDIO-VASCULAR

PATIENTS INTELLIGENTLY

We will analyse the scenario presented in the

previous section, in a practical application, and

while doing this, we will elaborate our innovative

ideas, that have already been presented in Section 2.

Logically, the identification of the domain-

imposed requirements should be firstly done. The

entities and some of their activities, in a typical

scenario, are represented in Figure 3.

Figure 3: Entities and activities in a typical scenario.

In the Figure, the BAN (Body Area Network) is

associated with the Patient but it is another entity

because it is not the patient who controls the BAN

sensors but they are performing their tasks on their

own, together with the BAN intelligent devices. The

BAN usually sends monitoring information to the

Portal (1a) and in cases of a (sensed) emergency it

can also send an emergency warning (1b). We will

consider only the emergency case further. Hence,

following the warning (1b), the Portal should send

ACT4SOC-EHST 2009 - 4th International Conference on Software and Data Technologies

418

an alarm to a specialized nurse (2) and it should

transmit the sensor readings (3). At the same time,

instructions could be given to external devices, such

as cameras in elevators, for instance. This triggers

the devices to send some actual information to the

specialized nurse (5) who can manage in turn to

control these devices for even better results (6).

Sometimes, when the case appears to be of great

complexity, the specialized nurse may ask a junior

cardiologist to get involved in the decision making

(8), supported by information concerning the patient,

which can be received from the Portal (7). Based on

all the information and the potential input of the

junior cardiologist, the specialized nurse should

decide whether the situation is urgent or not. If not,

then a trained nurse is to be asked to deliver help

(9b). In case of emergency nevertheless, the

specialized nurse must ask help from an ambulance

(9a). No matter what the choice, the patient is to

receive help – either from the trained nurse (11) or

from the emergency team (12).

This information can be reflected usefully in

other models, as according to the SDBC approach

(Shishkov, 2005).

Abbreviations:

bc – Business Component ssm – Software specific. model

bk – Business CoMponent sc – Software Component

glbk – General Bus. CoMponent sk – Software CoMponent

gcbk – Generic Bus. CoMponent

Figure 4: SDBC Approach (Shishkov, 2005).

As presented in Fig. 4, we consider a Business

System (with a static perspective and a dynamic

perspective, which both can be projected on the

model we have presented in Figure 3; we omit a

discussion on these modeling transformations for

reasons of brevity) from which Business

Components are to be identified (these are just parts

of the Business System). The component should be

then reflected in a relevant model – a Business

CoMponent (these are business models (Van Hee &

Reijers, 2000) that are to be used as foundation in

deriving the specification of an automated system).

Another way for arriving at a Business CoMponent

is through re-use, which we also omit for brevity.

The Business CoMponents should then be

elaborated with more domain-imposed requirements,

in order to add elicitation on the particular context in

which its corresponding Business Component exist

within the Business System, and these are

elaborations added to the relationships expressed in

Figure 3. Then, a mapping towards a software

specification model should take place (Rational:

OMG, 2007), through a modeling transformation,

taking into account that all that is not to be

automated appears as the environment of the ICT

system (Liu, 2000) and all that affects its

functionality – as context.

We are therefore able to define generic ICT

components that are adjustable based on the

particular situation in the business world. These

could be used in the specification of context-aware

applications that effectively support patients. The

component-based approach has a crucial advantage

with respect to the service-orientation since

technical components and corresponding business

services are to be considered in concert, setting up

an orchestration of the services with the users (not

burdened with technology) and adequately tracing to

the technology, keeping track also which part of the

delivered functionality is the responsibility of an

application component and which part is the

responsibility of the underlying infrastructure.

On the basis of this study, we claim that

components are a good foundation for service-

orientation and that service-orientation in turn is a

good foundation for context awareness (because

context awareness means different functionality

versions, which naturally projects to different related

services). All this in combination can be of

particular value, nevertheless if only the real-life

information is adequately captured and processed, as

we have suggested in this section.

5 CONCLUSIONS

In this paper, we have reported follow-up research

from previous studies on context-aware application

support to patients, mainly envisioning tele-

monitoring. We have added contribution on how to

better describe, present and capture the real-life

ENHANCING CONTEXT ANALYSIS WITH INTELLIGENCE IN PROVIDING e-HEALTH SERVICES - Less

Infrastructure Dependency in Supporting Cardio-Vascular Patients

419

information and reflect it in software components in

a consistent way.

We have omitted for brevity discussions on

modeling transformations that have been considered

exhaustively in literature, especially in materials

focusing on model-driven engineering. What is

missing in most of these materials nevertheless is

sound guidelines on the identification of

computation-independent models and in the paper

we have delivered some useful contribution relevant

to this. Furthermore, we have put some concreticity

with regard to more general results from previous

studies, considering especially the health care

perspective where context-awareness is of crucial

importance. Finally, we have also illustrated

partially the early stages of deriving a computation-

independent model, by emphasizing on the need for

structuring information as good as possible.

In the analysis preceding the proposed

methodological guidelines, we have suggested how

multi-level context states can be incorporated and

how context states can be considered from different

perspectives, for the design of flexible and adaptive

ICT applications.

The achieved results can be generalized to also

derive more fundamental knowledge on the possible

ways in which context-aware solutions can be

applied.

We plan for further research reflecting the

mechanisms of the SDBC approach for structuring

early requirements in a separate methodology,

applied in different domains including the health-

care domain.

REFERENCES

A-MUSE Project, 2008: http://a-muse.freeband.nl.

Liu, K., 2000. Semiotics in Information Systems

Engineering, Cambridge University Press. Cambridge.

Mei, H., Widya, I.A., Broens, T.H.F., Pawar, P., Van

Halteren, A.T., Shishkov, B., Van Sinderen, M.J.,

2007. A Framework for Smart Distribution of Bio-

signal Processing Units in m-Health. In ICSOFT’07,

2nd International Conference on Software and Data

Technologies. INSTICC Press.

Meinert, C.L., 1986. Clinical Trial: Design, Conduct and

Analysis, Oxford University Press, New York.

Moran, T.P. and Dourish, P, 2001. Introduction to

Context-Aware Computing, Special Issue of Human-

Computer Interaction, Volume 16, IBM Almaden

Research Center, University of California, Irvine.

Rational / OMG UML, 2007. Unified Modeling Language,

Object Management Group, http://www.omg.org/uml.

Shishkov, B., 2005. Software Specification Based on Re-

usable Business Components, Delft University Press,

Delft (PhD Thesis).

Shishkov, B., Van Sinderen, M.J., Liu, K., Du, H., 2008.

Norm Analysis Supporting the Design of Context-

Aware Applications. In ICEIS’08, 10th International

Conference on Enterprise Information Systems.

INSTICC Press.

Shishkov, B. and Van Sinderen, M.J., 2008. On the Design

of Context-Aware Applications. In I-WEST’08, 2nd

International Workshop on Enterprise Systems and

Technology. INSTICC Press.

Van Hee, K. and Reijers, H.A., 2000. Using Formal

Analysis Techniques in Business Process Re-Design.

W. van der Aalst et al. (Eds.): Business Process

Management, LNCS 1806.

Von Wright, G. H., 1963. Norms and Action - a Logical

Enquiry. Routledge and Kegan Paul, New York.

World Health Organization - WHO. 2001. International

Classification of Functioning, Disability and Health:

ICF. Geneva, Switzerland.

ACT4SOC-EHST 2009 - 4th International Conference on Software and Data Technologies

420