A BPM-BASED MOBILE U-HEALTH SERVICE FRAMEWORK

Dongsoo Han, In-Young Ko, Sungjoon Park, Minkyu Lee

School of Engineering, Information and Communications University,119, Munjiro, Yuseong-gu, Daejeon, Korea

Suntae Jung

Samsung Electronics, 416, Maetan-dong,Youngtong-gu, Suwon, Kyounggi-do, Korea

Keywords: e-Health, u-Health service platform, ontology, mobile, BPM.

Abstract: The integration of mobile bio-sensors and cellular phones opens a new horizon for healthcare service.

Mobile u-health service, which usually incorporates mobile bio-sensor attached cellular phones, provides

users real time healthcare services at the right time in the right manner. While the u-health services may

look different from the service point of view, they often share many common features at various levels such

as the service structure, unit service, and data levels. Thus, it is necessary to have a common platform on

which various u-health services can be developed by effectively sharing and reusing the common features

and services rather than developing the services independently from the scratch. In this paper, we propose a

mobile u-health platform that provides core functions and facilities to develop mobile u-health services.

Main elements of the platform include the u-health ontology and common data structures, and Business

Process Management (BPM) based service integration framework. The platform provides commonly

reusable features and functions in developing u-health services. According to the early evaluation, our

platform turned out to have strength in terms of service flexibility, accessibility, evolvability, reusability,

adaptability, interoperability and guideline provision for developing u-health services.

1 INTRODUCTION

The integration of mobile bio-sensors and cellular

phones opens a new horizon for healthcare service.

It enables us to provide various healthcare services

in mobile environment. Actually, couple of mobile

u-health services are developed and announced to

the public. But, currently available mobile u-health

services are very limited in terms of scopes and

types of the services. This situation will be changed

as more mobile bio-sensors become available and

the number of mobile u-healthcare users increases.

Meanwhile, due to the lack of commonly

available mobile u-health service development and

running platform, current mobile u-health services

are usually developed in ad hoc and separate manner.

Although u-health services may look different from

the service point of view, they often share many

common features at various levels such as the

service structure, unit service, and data levels. Thus,

it is necessary to have a common platform on which

various u-health services can be developed by

effectively sharing and reusing the common features

and services rather than developing the services

independently from the scratch.

In this paper, we propose a mobile u-health

platform that provides core functions and facilities to

develop mobile u-health services. Main elements of

the platform include the u-health ontology and

common data structures, and Business Process

Management (BPM) based service integration

framework. The platform provides commonly

reusable features and functions in developing u-

health services.

The platform has several unique features. First,

the platform interprets and treats mobile u-health

service as service process and it extends BPMS to

healthcare service. As a consequence, the platform

can provide functions and facilities of general

Business Process Management System (BPMS). In

regard with the u-health service process, we define a

typical mobile u-health service process template and

deploy the process template on the platform. Second,

the platform is equipped with a very unique matrix

based patient group identification method. The

method is quite useful in mobile environment in

which less precise bio-signals data is frequently

gathered from a large number of users. Third, the

platform provides several advanced features and

functions by incorporating ontology technologies in

110

Han D., Ko I., Park S., Lee M. and Jung S. (2008).

A BPM-BASED MOBILE U-HEALTH SERVICE FRAMEWORK.

In Proceedings of the First International Conference on Health Informatics, pages 110-117

 SciTePress

defining mobile u-health services and disease

inferring processes.

We implemented the prototype of the proposed

platform and evaluated the prototype based on the

various software design criteria. According to the

early evaluation, our platform turned out to have

strength in the aspects of service flexibility,

accessibility, evolvability, reusability, adaptability,

interoperability and guideline provision for

developing u-health services.

2 RELATED WORK

Konstantas et al. (Konstantas et al., 2006) have

presented a Java-based service platform for remote

monitoring of patients. They collect patient data

using medical sensors integrated into the system

which captures six different bio-signals: ECG, HRV,

pulse oximetry, temperature, marking, respiration,

and motion/activity. The captured bio-signals are

delivered to remote healthcare experts for analysis.

However, the system does not provide any means to

manage the health care process between the experts

and the patients.

There were some attempts to use a workflow

management system or Business Process

Management System (BPMS) for the integration of

the Patient Record Manager (PRM) module and the

Personal Organizer (PO) system in healthcare

support (Pappas et al., 2002). Healthcare and

emergency response organizations are the users of

such solutions. One of the drawbacks of a healthcare

system without BPM is insufficient handling of

incomplete task definitions (Broens et al., 2005).

Oliver et al. (Oliver and Flores-Mangas, 2006)

have designed and developed MPTrain, a mobile

phone based system that utilizes the effects of music

in physical exercises. MPTrain enables users to

more easily achieve their exercise goals by

constantly monitoring their physiology such as HRV,

and by selecting/playing music with specific features

that make the users speed up, slow down or keep the

pace to maximize the exercise results.

The work done by Jovanov et al. (Jovanov et al.,

2003) is closely related to the healthcare monitoring.

They capture HRV to quantify the levels of stress for

a group of individuals undergoing military training.

They collect HRV data of military personnel prior to,

during and after training and assess their stress

levels and predict their stress resistance.

However, none of the work support a systematic

approach in developing mobile u-health services by

using a common u-health service platform like the

one described in this paper.

3 MOBILE U-HEALTH SERVICES

A mobile u-health service system is a total system

that enables u-health services to be coherently

provided to the users. The system integrates various

components such as bio-sensors, cellular phones,

associated software, and devices that are essential

for u-health services. In this section, we describe the

core components that constitute mobile u-health

services.

We have identified the main categories of the

core components that play essential roles in

providing u-health services. Bio-data gathering and

management, bio-data analysis, and knowledge

extraction and decision support are the service

categories that we identified based on the steps or

roles involved in the u-health service process.

3.1 Bio-data Gathering and

Management

A mobile u-health service starts its function with

periodically or randomly gathering input data i.e.

capturing the bio-signal data from users. We use

some bio-sensors that are wearable by the users or

imbedded into cellular phones. Thus, the bio-sensor

devices and cellular phones, which act as a gateway

between the bio-sensors and the u-health server, are

the essential components for gathering input data.

Besides, questionnaires that can be provided via

cellular phones are necessary to obtain information

that cannot be gathered from bio-sensors. The

physical symptoms that a user experiences, the

location of the user, and the weather information are

examples of such information that need to be

obtained directly from the users by using the

questionnaires. We have developed a generic

questionnaire composer to accommodate various

symptoms and environmental information in making

questionnaires.

Our mobile u-health service platform provides

the sensing modules and questionnaire interfaces

independently from the core functionality of u-

health services. This improves the reusability of the

sensing modules and questionnaires for different

healthcare services.

3.2 Bio-data Analysis

Since huge amount of bio-data need to be gathered

and analyzed in mobile u-health services, it is

essential to have an efficient data structure that

allows the system to effectively store and manage

bio-data. We investigated that a matrix is one of the

good candidates for storing and analyzing a large

A BPM-BASED MOBILE U-HEALTH SERVICE FRAMEWORK

111

quantity of data. We devised a bio-signal and

symptom combination matrix, in which the

appearances of bio-signal and symptom combination

pairs of a normal user group and those of a patient

user group are registered. We call the matrix as the

Disease Combination Appearance Probability

(DCAP) matrix. Two DCAP matrices are created,

one for normal groups, and another for patent groups.

The accumulated data in DCAP matrices becomes

the basis of the next step of the u-health service

process, the knowledge extraction and decision

support.

3.3 Knowledge Extraction and Decision

Support

Once a large amount of bio-data is accumulated,

knowledge extraction and decision support for

diagnosis can be provided by using data mining

technology. Sometimes, we can use well established

health indices to diagnose certain diseases to support

some u-health services. However, in many cases,

new health indices may need to be developed by

performing machine learning or pattern recognition

based on the accumulated data.

For the accumulation and management of bio-data

and information obtained from questionnaires, we

have developed data ontology. Based on this data

ontology, symptom, disease and bio-signal data can

be archived in a structured manner. Some additional

information such as a weight value to represent the

degree of association between each input data and a

certain disease type is assigned to the data ontology.

Note that the weight values are defined not by users

but by domain experts. The data ontology grows as

new services and/or disease information are

incorporated, and this contributes to make our

platform evolvable.

One assumption that we made in identifying

health indices is that diseases can be diagnosed

based on the combination of bio-signals and

symptom information. Another assumption is that

bio-signals and symptom data of normal and patient

groups can be obtained in some way. If the

difference between the data gathered from the

normal group and the patient group is obvious, the

interrelation patterns between bio-signals and

symptoms provide good criteria to classify users into

the two groups. A statistical equation is devised

based on the DCAP matrices to discern a normal

group from a patient group. Once bio-signals and

symptoms of a disease or a service are stored in

DCAP matrices, (Eq. 1) is used to compute the

probability for a person who has the CP(p) bio-

signals and symptom pairs to belong to the patient

group of the disease. X(p) and Y(P) denote weight

vectors of bio-signals and symptoms respectively.

We leave the detailed explanation to our previous

work and we do not delve into the details in this

paper.

P(p ∈ Patient Group │CP(p)) =

∑∑

⋅

uiu

pDCAPpY

)]

)(

)()(

(

)(

[

(Eq. 1)

4 MOBILE U-HEALTH SERVICE

SCENARIO

Fig. 1 illustrates the generic service scenario for

mobile u-health services. In the first step of the

service scenario, users fill out questionnaires to

provide information about physical symptoms and

their environments, which cannot be obtained from

bio-sensors. The sensors embedded in cellular

phones capture necessary bio-signal and relay the

data to the u-health server.

After gathering bio-data from questionnaires and

sensors, a mobile u-health service process is initiated

by an associated BPM engine. The next activity of

the scenario process is to store the relayed data to a

database so that the history of bio-data of a person

can be persistently kept for further analyses.

Figure 1: Mobile u-health service scenario process.

In the data analysis and decision support steps,

the data ontology manager, which keeps

semantically structured data for a specific set of

diseases, plays a key role in identifying potential

diseases based on the symptoms and bio-signals. For

each symptom and bio-signal, the data ontology

manager assigns a weight value that represents the

degree of association between the symptom or bio-

signal and a certain disease.

The final diagnosis decision is made by (Eq. 1).

The computed probability is delivered to the user to

show whether the user belongs to the patient group

or not. One of the unique features of our approach is

the user feedback mechanism. Using the feed back

HEALTHINF 2008 - International Conference on Health Informatics

112

mechanism, users can send their feed back on

analysis results (the diagnosed diseases) as the

response to the system. Based on this feedback data,

the system adjusts weight values of corresponding

symptoms and bio-signals to provide more

personalized services.

The u-health service scenario itself, and the data

ontology and the DCAP matrix components are

independent from any specific u-health services.

Therefore, the platform we designed is considered to

be a general platform. In other words, the u-health

service scenario and its supporting components can

be used for a variety of u-health services. A mobile

u-health service for specific disease can be

implemented by extending the service scenario.

Please see Section 6 for more details.

5 PLATFORM ARCHITECTURE

The mobile u-health service platform is a

middleware that enables the integration of diverse

services by using BPM. It serves as the hub to

integrate techniques and functions that are

associated with mobile u-health services, and

provides an environment to develop and run the u-

health services. Fig. 2 illustrates the architecture of

the platform that shows the major components and

the connections to the surrounding elements in the u-

health service framework.

Since cellular phones play the role of a gateway

between bio-sensors and servers, mobile message

handling is essential for the platform. The mobile

message handling module relays all the messages

from bio-sensors to the server. Not only the bio

signal data but also service request messages are

delivered by the message handling module.

Sometimes, it contributes to filter out some noise

signals from the received messages.

The bio-data delivered to a server is stored and

managed by the huge temporal data management

module. The bio-data is stored in diverse forms so

that various services can utilize the data to perform

their functions.

Data mining and pattern recognition techniques

are used to identify health index from the

accumulated bio-data. Also, an external or internal

expert system may refer to the data as feedback

information. In order to support this, the database

schema of the temporal database needs to be

designed to satisfy the requirements of data mining

or pattern recognition techniques and expert systems.

Online Services

Mobile E

Health Platform

Patient

Medical Info

E-Health

Information

Medical

Knowledge

Ontology

Expert

System

Expert

System

Cell p ones

PDAs

E- health Cards

Sensors

Health Process

Management

Mobile Message

Handling

Dynamic Service

Coordination

User

Management

Huge Temporal

Database Management

Data Mining/

Pattern Recognition

Health Process

Health Portal

Patients

Clinicians

Exercise Management

Stress Management

Weight Management

ECG/MCG E

Health

Management

Blood Sugar

Mang

Fatigue Management

User Applications

Expert

System

Expert

System

Expert

Systems

Expert

Systems

Sleeping Management

Figure 2: Mobile u-health service platform architecture.

As explained in Section 4, in order to develop a

mobile u-health service on the service platform, the

u-health service should be defined in a form of

process containing steps like bio-data gathering,

storing, analysis, and result reporting. The u-health

process block in Fig. 2 denotes a set of mobile u-

health processes derivable from the u-health service

scenario process explained in Section 4.

The u-health process definition tool allows

developers to easily define new mobile u-health

services. Mobile u-health services defined in a form

of process are controlled and enacted by the u-health

process management module. The u-health process

management module provides not only the

enactment function but also monitoring and

administration functions for u-health processes.

The mobile u-health management module and u-

health process definition tool play a key role in

making the platform evolvable. When a new mobile

u-health service process is defined, reusable process

templates, steps, and data structures are identified

and registered to the server for later use. The

management module ties together a set of u-health

services into a group by specifying execution

dependencies and the dataflow between the services.

There may be also some constraints that prevent a

particular service to be initiated until some other

services finish their functions.

The user management module is essential for

providing personalized service to individual users.

The user management module stores user profile

information such as age, gender, and occupation.

Since a user is a participant in a mobile u-health

process as well, this module is closely connected to

the participant information in the u-health process

management module.

The dynamic service coordination module

executes a service process by initiating and

synchronizing services during runtime. It also

ensures reliable u-health service execution by

A BPM-BASED MOBILE U-HEALTH SERVICE FRAMEWORK

113

replacing one service with an alternative one when a

fault occurs in the service or the user's requirements

are changed. Data mining and pattern recognition

functions may need to be developed for specific u-

health services. Whenever such functions become

available, they are placed on the data mining/pattern

recognition module. An expert system engaged with

a u-health service may need to access the functions

in the data mining/pattern recognition module to get

a decision making support.

Mobile u-health services are accessible not only

from mobile devices, but also through a Web

browser. Web users can connect to a healthcare Web

portal, and access their health information. The

healthcare portal also provides useful services such

as registering user information, composing

questionnaires, and browsing expert advices.

Especially, the Web portal allows users to access

services that cannot be provided through mobile

devices due to the limitations of the devices such as

the small screen size, and memory and processor

constraints.

6 IMPLEMENTATION

6.1 Mobile u-Health Modeling Tool

We have implemented a prototype of the u-health

process modeling tool that allows application

developers to semi-automatically compose mobile u-

health services.

Fig. 3 shows the prototype of our mobile u-

health process modeling tool. The tool is

implemented in Java™ on Eclipse Foundation's

Eclipse™ platform. Part (a) of Fig. 3 shows the

canvas of the visual business process editing tool.

The tool graphically shows the basic u-health service

process template, and allows application developers

to specialize and extend the process to meet their

requirements. In the course of defining the process,

the process modeling tool recommends a set of

candidate services that can be used to implement

each step of the process, and are interoperable with

other services that are already put in the process. It

also automatically inserts adapters and converters

when it finds some syntactic and semantic

mismatches between services in the process. Part (b)

of the modeling tool is the service recommendation

tool that shows a list of candidate services for each

step in a process. When a user marks a service in a

service process, the tool lists the services that are

interoperable with the marked service. Part (c) of Fig.

3 is the ontology-hierarchy browser that allows

developers to browse through the service hierarchy.

Figure 3: Prototype of the service composition tool - (a)

Visual business process editing tool; (b) Service

recommendation tool; (c) Ontology-hierarchy browser.

6.2 Mobile u-Health Ontology

Manager

Figure 4: Ontology manager interface.

As explained earlier, in our platform, u-health data

such as symptoms, diseases, and bio-signals, are

systematically managed by constructing their

ontology. In addition, services are classified and

managed based on their functional ontology. The

ontology manager allows experts to easily manage

the u-health ontology. Fig. 4 shows the user

interface of the ontology manager. By using the tool,

experts can browse, add, remove, and search u-

health ontology.

6.3 Mobile u-Health DCAP Matrix

In our u-health service platform, the interrelation

patterns are identified in the learning and diagnosis

stage based on the patterns that is constructed in the

prediction stage. In the learning stage, interrelation

patterns of bio signal data and physical symptoms of

the normal and patient groups are identified. We

assume that enough learning data for the

identification of interrelations is available for this

stage.

HEALTHINF 2008 - International Conference on Health Informatics

114

In the learning stage, interaction frequencies of

bio-signals and physical symptoms from the normal

and patient groups are counted and registered in the

Combination Interaction (CI) matrices. Each CI

matrix contains combination patterns of specific bio-

signals and physical symptoms of the normal or

patient group with frequency scores. We integrated

both CI matrices into the DCAP matrix. In the

DCAP matrix, each element has a probability which

means how likely the combination pattern of the

element can be shown in a patient group. In the

prediction stage, bio signals and physical symptoms

of an unidentified person are submitted to the

prediction system. Then, the prediction system

determines how likely the person can be categorized

into the patient group. Since the DCAP matrix is

constructed based on the CI matrix, we can easily

figure out which bio-signal and physical-symptom

combinations contribute to a certain diagnosis. In

Fig. 5-(b), shaded areas are corresponding bio-signal

and symptom combination elements, and a

probability, ranging from 0 to 1, is calculated by

using (Eq. 1).

The DCAP matrix enables diverse forms of bio-

signals and physical symptoms to be used for

analyses. As shown in Fig. 5-(a), users can compare

their position in the matrix with those of others. In

addition, when we use the DCAP matrix, finding

primary bio-signal and physical symptom pairs that

contribute for the user to be classified into the

patient group is relatively easy. As a result, the

prediction system can show the causes of a certain

disease to users in a comprehensive manner. The

more clinical data is accumulated in the platform,

the more services the platform can provide in the

future.

Figure 5: Disease combination appearance probability

matrix – (a) Disease distribution chart for a learning set;

(b) Test result for a user health condition by the DCAP

matrix.

6.4 Mobile Client

Due to the diverse types and characteristics of bio-

sensors and various application scenarios, there are

many different requirements imposed on mobile u-

health systems. As a mobile gateway, a mobile

device is responsible for collecting data from sensors

by periodically sensing the human body.

Once a communication link is established, bio-

data and functions are delivered to the u-health

server using the wireless interface. The interface

sends and receives XML messages to and from BPM.

An XML message can a flexible structure to

facilitate transmission of different data types and

formats generated based on various bio-signals and

physical symptoms. By parsing the XML message,

the server classifies bio-data into several types and

then the server responds with the results of classified

bio-data in an XML message.

After forwarding bio-data to the server, the

application changes its state to the stand-by state

until it receives a response message from the server.

No event or signal can be pushed to the client

asynchronously. A process polling mechanism is

used to continuously pull the event of clients'

requests to the decision support step of the u-health

service process. When the server process is

completed, the result is delivered to the client.

Figure 6: WIPI Application Mounted on KTF Emulator &

Samsung Anycall SPH-V8900.

Once the client receives the probability of a

disease, the result is graphically displayed on the

mobile device. Figure 6 shows a graph displayed on

a cellular phone after receiving the results from the

server. If the user does not agree with the results,

he/she can send a feedback to the server to revise

his/her own weight vectors. The DCAP matrices are

updated if the feedback data is sufficiently

accumulated.

A BPM-BASED MOBILE U-HEALTH SERVICE FRAMEWORK

115

7 EVALUATION

We considered some quality attributes in designing

the mobile u-health service platform, which is a

large-scale service platform. We think that flexibility,

accessibility, evolvability, reusability, adaptability

and interoperability are the essential requirements

for large-scale service platforms.

Table 1: Evaluation of the Mobile u-Health Service

Platform.

Core Com-

ponents

Design

Goals

Bio-data

gathering and

management

Bio-data analysis

Decision

support

Web

Portal

Ontol

-ogy

DCAP

Matrix

BPM

Flexibility

○

△

○

○ ○

Accessibility

○ ○ × ×

△

Evolvability

N/A N/A

○ ○

△

Reusability

△

○ ○

△

○

Adaptability

△ △ △

○ ○

Interoperability

○ ○

△ △

○

Remarks: ○: Supported, ×: Not Supported, △ : Insufficient,

N/A: Not Applicable

Table 1 summarize these quality attributes and

explain how the core components of our service

platform contribute to satisfy those requirements.

The following sub-sections discuss the design

rationales of our platform to make it satisfy each of

the quality attributes.

7.1 Flexibility

There are some reasons why the mobile u-health

service platform needs to be flexible. Different sets

of bio-sensors such as ECG, HRV, and temperature

sensors need to be supported for different u-health

services. Furthermore, some of the sensors may need

to be replaced with other types depending on the

mobile-device types and some other constraints. In

addition, the functionality provided by the platform

or the user interface on a mobile device may need to

be customized for a specific user group. Also, the

bio-signals and symptoms that the healthcare server

handles may need to be changed based on the

disease types to cover by specific u-health services.

In order to support flexibility, we have

developed a Web-based questionnaire composer. It

can easily accommodate new questionnaires or

updates of questionnaires for new u-health scenarios.

In addition, since we use the BPM process modeling

tool for the definition of u-health service processes,

we can easily update the defined process when a

change is required. This enables the platform to be

used for a variety of u-health services with different

scenarios. The ontology-based data management and

the DCAP matrix are the features that improve

flexibility of our platform as well. The structure of

ontology and DCAP matrix can be dynamically

changed based on users' feedback information.

7.2 Accessibility

The multi-channel approach, which makes users'

health information accessible via both mobile and

Web-based interfaces, supports a good access

environment that enables the benefits of hybrid

accessibility. In the healthcare service environment,

a real-time and mobile disease-checking function

can be supported using mobile devices whereas the

in-depth analysis of the disease can be provided on

the Web. This makes the users to access their health

information in various degrees of detail.

7.3 Evolvability

As discussed in Section 3, the data ontology evolves

as new data and feedback information from users are

accumulated. In addition, the DCAP matrices used

in our u-health service platform are also evolvable.

According to the feedback on the analysis results,

the DCAP matrices appropriately change their

values for more precise and personalized analyses.

7.4 Reusability

The BPMS-based service development mechanism

makes service components reusable for various

types of u-health services. In other words, when a

new mobile u-health service is defined with the u-

health process definition tool, developers can reuse

various service components, and other assets in

different abstraction levels. Process templates,

activities, applications pertaining to an activity, and

data structures are the reusable assets in our platform.

When we consider that most u-health service

processes shares the basic u-health service scenario

described in Section 4, many components of a u-

health service process can be reusable by other u-

health processes. Since our platform is based on

BPMS, it is competitive in supporting reusability.

7.5 Adaptability

The circumstances and environment surrounding

mobile u-health services are ever changing. New

bio-sensors, which produce new forms of signals or

HEALTHINF 2008 - International Conference on Health Informatics

116

signals never handled before, may become available,

and new service scenarios may be developed. For

example, a mobile u-health service may be

developed to handle only a single type of sensor. But

sometime it may need to handle multiple sensors in a

bundle. Then, the implementation of the u-health

service needs to be modified to cope with the

changes. Since our platform maintains a property

file that keeps the descriptions about the sensor

types, the platform can adapt to the change more

efficiently. This property file enables multiple

sensors to be linked to a mobile device and to

transmit the sensor data over a single wireless link to

the u-health server.

When hospitals and insurance companies are

engaged with the mobile u-health service scenario

described in Section 4, the u-health service scenario

needs to be extended. Such kind of environmental

change circumventing u-health services may be

frequent in real situations. Since u-heath services are

defined in the form of processes using the BPMT

tool in our platform, they can adapt to such changes

more efficiently by adding new service components

and/or by replacing some of the service components

with alternative ones.

7.6 Interoperability

One of important criteria for designing the mobile u-

health service platform is interoperability. BPMS is

usually equipped with facilities for supporting

interoperability. Since our platform is based on

BPMS, the facilities of BPMS for interoperability

can be shared in the mobile u-health service

platform. The remote applications and systems can

be integrated with u-health services in our platform

without any extra work. The Web Services API for

BPMS and the Web portal provide an easy way of

exchanging information between processes.

8 CONCLUSIONS

In this paper, we have identified several core

components of the u-health service scenario process,

and described the overall architecture of the mobile

u-health platform. We have also developed essential

functions and facilities that allow service developers

to effectively use the core components to develop

various mobile u-health services with less effort.

Our mobile u-health service platform is very

unique in that it adopts BPMS as its underlying

platform, and u-health services are designed as

service processes. The standard u-health service

process provides a guideline to u-health service

developers. They can specialize and/or extend the

service process template to develop their own u-

health services. Six design goals are identified for

the mobile u-health platform, and we have tried to

achieve them in our BPMS-based u-health service

platform.

One of the lessons that we learned while

working with the mobile environment is that

different trade-offs need to be made for different

circumstances. For example, we need to consider

resource limitations on mobile devices,

communication bandwidth, and constraints on user

interfaces to make a trade-off between different

quality of services for different environments and

different user groups.

There are also some pending works to be done to

make the platform more secure and reliable. We are

currently investigating how to support the features of

managing personal healthcare data securely, and

enhancing the performance by compressing

messages exchanged between mobile devices and

the u-health server.

REFERENCES

D. Konstantas, R. Bults, A. Van Halteren , K. Wac, V.

Jones, I. Widya, R. Herzog, B. Streimelweger,

“Mobile Health Care: Towards a commercialization of

research results”, In proceedings of 1st European

Conference on eHealth - ECEH06 -Fribourg,

Switzerland, pp.12 – 13, October 2006.

Pappas, C. Coscia, E. Dodero, G. Gianuzzi, V.

Earney, M., “A Mobile E-Health System Based on

Workflow Automation Tools”, Computer-Based

Medical Systems. Proceedings of the 15th IEEE

Symposium on pp.271 – 276, June 2002.

Broens, T.H.F., van Halteren, A.T., van Sinderen, M.J.,

Wac, K.E. “Towards an application framework for

context-aware m-health applications”, In: EUNICE

2005 "Networked Applications". 11th open European

Summer School, pp.6-8 July 2005.

N. Oliver , F. Flores-Mangas, “MPTrain: a mobile, music

and physiology-based personal trainer”, ACM

International Conference Proceeding Series; Vol.159,

pp.21 – 28, 2006.

E. Jovanov, D. Raskovicl, A. 0. Lords, P. Cox, R. Adharni,

F. Andrasik, "Stress monitoring Using a Distributed

Wireless Intelligent Sensor System“, in IEEE

Engineering in Medicine and Biology Magazine, pp.

49-55, May/June 2003.

A BPM-BASED MOBILE U-HEALTH SERVICE FRAMEWORK

117