A WIRELESS APPLICATION THAT MONITORS ECG SIGNALS

ON-LINE: ARCHITECTURE AND PERFORMANCE

Jimena Rodríguez, Lacramioara Dranca, Alfredo Goñi and Arantza Illarramendi

University of the Basque Country (UPV/EHU).LSI Department. Donostia-San Sebastián. Spain

Keywords: Wireless Application, Mobile Co

mputing, Wireless Network, ECG Monitoring System

Abstract: In this paper, we present an innovating on-line monitoring system that has been developed by applying new

advances in biosensors, mobile devices and wireless technologies. The aim of the system is to monitor

people that suffer from heart arrhythmias without having to be hospitalized; and therefore, living a normal

life while feeling safe at the same time. On the one hand, the architecture of the system is presented; and, on

the other hand, some performance results and implementation details are explained showing how the

previous solution can be effectively implemented and deployed into a system that makes use of PDAs, and

wireless communications: Bluetooth and GPRS. Moreover, special attention is paid to two aspects: cost of

the wireless communications and notification latency for the detected serious heart anomalies.

This work was mainly supported by the University of the Basque Country and the Diputación Foral de Gipuzkoa (co-

supported by the European Social Fund)

1 INTRODUCTION

Innovations in the fields of PDAs, wireless

communications and vital parameter sensors enable

the development of revolutionary medical

monitoring systems, which strikingly improve the

lifestyle of patients, offering them security even

outside the hospital.

In this context we are developing a system that

akes advantage of the latest advances in the

technology in order to monitor on-line, people that

suffer from heart arrhythmias. The system allows an

anywhere and at any time monitoring and provides

to its users the adequate medical assistance. So, the

patient could have a normal life in his/her habitual

environment without being constrained to a hospital

room. The patient's tool, which replaces the

traditional monitor (Holter) and supports Bluetooth

technology, is reflected in a standard PDA that is a

small, handheld computer that captures, processes,

detects, analyzes and notifies possible abnormalities

to a medical unit through the wireless network

(GPRS) from anywhere and at any time. Moreover,

the Bluetooth communication makes this tool even

more comfortable for the user, replacing the cables

of the sensors that pick up the cardiological signals.

Concerning related works, on the one hand, there

are se

veral commercial tools designed to monitor

heart patients outside the hospital; from the

traditional Holter (Despopoulos, 1994) that simply

records heart signals named ECG

(electrocardiogram), for 24 or 48 hours, which are

later analyzed in the hospital, until the modern

cellular phones e.g Vitaphone (Daja, 2001) that, in

case of an emergency, can record the signals through

the metal electrodes situated on its back and transmit

them to the cardiac monitor center situated in the

hospital. There are other commercial monitoring

systems that use PDAs to store the ECG signals, e.g.

Ventracor (Ventracor, 2003), Cardio Control (Cardio

Control, 2003). For these systems additional features

like GSM/GPRS transmission to an analyzing unit

are also being developed.

On the other hand, in the research m

onitoring

area, stand out several research projects like:

@Home (Sachpazidis, 2002), TeleMediCare

(Dimitri, 2003), or PhMon (Kunze, 2002), whose

aims are to build platforms for real time remote

monitoring.

All these systems are continuously sending

ECGs to a

medical center through a wireless

communication network, where the signals are

138

Rodríguez J., Dranca L., Goñi A. and Illarramendi A. (2004).

A WIRELESS APPLICATION THAT MONITORS ECG SIGNALS ON-LINE: ARCHITECTURE AND PERFORMANCE.

In Proceedings of the Sixth International Conference on Enterprise Information Systems, pages 138-145

DOI: 10.5220/0002640101380145

 SciTePress

analyzed. In spite of the advantages these kinds of

systems provide in relation to holters, they still

present main problems related to the fact that the

analysis is not performed in the place where the

signal is acquired. Therefore, there is a loss of

efficiency in the use of the wireless network because

normal ECGs are also sent (and wireless

communications imply a high cost); and, if the

wireless network is not available at some moment

(e.g. in a tunnel, in an elevator, etc.), there might be

a loss of ECG signal with the corresponding risk of

not detecting some anomalies.

Our proposal, the MOLEC system, is a PDA-

based monitoring system that records user ECG

signals and locally analyzes them in order to find

arrhythmias. In case of detecting a high risk situation

for the user, it sends an alarm with the

corresponding ECG signal through the wireless

network (GPRS) to a health center for further

analysis and medical assistance.

The advantages of this approach are that

provides 1) local analysis: even if wireless

communication with the health center were

unavailable, the signal could be analyzed locally at

the PDA; 2) low cost communication since not the

entire signal is sent; 3) fast medical response in risk

situations for the user; 4) accessibility: data recorded

in the system can always be queried whether locally

or remotely; 5) distributed computation: the local

analysis in each PDA implies a serious decrease of

computational costs in the health center; 6)

openness: it can be easy integrated in hospitals that

manage clinical data through the XML and HL7

standard (HL7, 2003), a representation of clinical

documents; 7) adaptability: possibility of working

with different kinds of ECG sensors; 8) simplicity:

making technical issues transparent to the users from

the point of view of software and hardware

components.

The goals of this paper are to present the global

architecture of MOLEC, and more specifically the

software modules needed in the PDA (in section 2);

and to introduce some implementation details (in

section 3) and performance results (in section 4),

focusing on two important aspects: minimizing the

cost of the wireless communications and obtaining a

reasonable notification latency for the detection and

notification of serious heart anomalies. Finally, in

section 5, we present the conclusions.

2 GLOBAL ARCHITECTURE

Three main components form the global architecture

of MOLEC (see figure 1, from left to right): 1) The

ECG Sensors that pick up the electric impulses of

the heart. These sensors are the “intelligent” chips

that communicate with the PDA through the

bluetooth protocol. 2) The PDA-Holter that acquires

the data signal in a PDA, records them, detects

abnormalities and notifies them immediately in case

they are considered serious. 3) The Molec Hospital

receives the user alarm signals that are shown to the

medical personal so that they can react promptly.

Figure 1: Architecture

2.1 ECG Sensors

The ECG sensors are carried by the user in order to

through the bluetooth protocol (Bluetooth, 2003).

Bluetooth is a new standard for very low cost, short-

range wireless communication. It enables different

types of equipment to communicate wireless with

each other and has been thought of as a cable

replacement becoming the fastest growing

communication standard ever.

Hence we consider that this technology has a

promising future for the area of the ECG sensors and

we developed the MOLEC project for the integration

with bluetooth ECG sensors.

ECG Sensor emulating module

Emulate Sensor

MIT-BIH

Sequence of 16 bit

0 1 0 1 0 1 1 1 0 1 0 1 1 0 1 1

Figure 2: ECG sensor emulating module

Unfortunately, nowadays ECG sensor providers

only sell their products with proprietary

electrocardio analyzer software. That is why, in our

case, the PDA communicates through bluetooth with

an ECG sensor emulator placed in a computer

device. The ECG signals are taken from a

recognized freely distributed database, namely MIT-

BIH Arrhythmia database (MIT-BIH, 2003), and

sent in real-time as bit sequences to the PDA

through the wireless network (see figure 2).

On the other hand, in the PDA-Holter, the

Acquisition module receives the bit chains and

translates them into a standard format that the whole

system understands.

A WIRELESS APPLICATION THAT MONITORS ECG SIGNALS ON-LINE: ARCHITECTURE AND

PERFORMANCE

139

2.2 Molec Hospital

The other system that interacts with the PDA-Holter

is the MOLEC Hospital whose main function is to

customize the PDA-Holter for each user and to

receive users' possible abnormalities. It maintains a

large database with all the users registered, their

historical and their progress. This could be very

useful for the specialists when diagnosing or taking

fast decisions in alarm cases.

Furthermore, MOLEC Hospital provides web

services that allow querying user data stored in the

PDA.

Those web services provide the same

functionality that holters have associated in the

specialized literature (Farreras, 2001) by a set of

reports, which enables physicians to analyze the data

easily and quickly and shows information about: 1)

automatic arrhythmia detection and identification; 2)

analysis of ST segments evolution; 3) ECG

parameters. Therefore the data in the database can be

queried, locally or remotely, to know different

aspects that can be related to the anomalous

situations.

In addition, the hospitals can easily incorporate

the MOLEC Hospital system into their

administration system since it does not interfere with

existing applications.

2.3 PDA-Holter

The PDA-Holter is the user tool of MOLEC. It is

responsible for acquiring the ECG data signal,

recording it, detecting abnormalities and notifying

them immediately in case they are considered

serious. The PDA-Holter is formed by several

modules that are explained in the next subsections.

ECG Signal Acquisition

The ECG signal acquisition module receives the

digital signal and converts it into a format

understandable by the whole system. It manages the

Bluetooth communication among the ECG sensors

and the PDA. Moreover it has to build signal

packages (the “source packages”) with a defined size

from the bit chains received from the ECG sensors.

In section 4, we present the experimental results that

have leaded us to define the correct size of these

packages.

Data Preprocessing Module

This module obtains the ECG signal in form of

source packages and detects the typical part of the

beat. An ECG signal consists of several beats that

succeeds with a frequency between 60 and 100 per

minute. A normal beat contains a P wave, a QRS

complex and one or two T waves. For the

arrhythmia detection it is significant the

identification of the presence or absence of these

waves, the points where start, end and the peaks of

them. We call these points ‘wave events’.

ECG Signal

Sequence of peaks and limits of

P,QRS,T waves (wave events)

Sequence of N wave events

Sequence of <beat, frequency, intervals>

ECG Signal Processing

Beat Detector

Data Preprocessing Module

Figure 3: Data preprocessing module

The goal of the data processing module is to

detect each beat from the original signal and the

points that characterize it. This work is even more

difficult if the signal has a high level of noise.

The task is realized in two steps (see Figure 3):

Firstly, the ECG signal is processed in order to

detect wave events (ECG Signal Processing). For the

implementation of the ECG Signal Processing we

have used, although slightly changed, a Fortran

implementation (Jané, 1997) of an on-line detection

algorithm developed by Pan & Tompkins (Pan,

1985) and provided by the recognized PhysioNet

(PhysioNet, 1997). This tool was not specifically

designed to be run in small computers like PDAs

and usually has been used to process long ECG

signals. However, we have been able to run it

successfully in the PDA using as input small ECG

signals (those corresponding to the “source

packages” previously mentioned). Only minor

changes related to memory management have been

made in the “open source” of Ecgpuwave with the

goal of increasing the processing speed.

Secondly, the sequence of wave events is

transformed into a sequence of beats, it is computed

the length of the relevant intervals and segments

determined by two wave events (Beat Detector).

Decision Support Module

Once the beats with the corresponding wave

events have been detected, the system can start the

arrhythmia detection, task which is realized by the

Decision Support Module (see Figure 4). Two main

steps take place during this analysis: identification of

the beat types and classification of the arrhythmias.

ICEIS 2004 - SOFTWARE AGENTS AND INTERNET COMPUTING

140

beat

Beat + beat type

Sequence of four beats

Rhythm

4. Beat Classifier

5. Rhythm Classifier

Decision Support Module

Figure 4: Decision Support Module

In order to classify the beat we have tested

seventeen methods (Rodriguez, 2003) from the

machine learning area and we have chosen the most

appropriate one for this kind of data: the decision

tree methods (Le Blanc, 1986) that approach

discrete-valued target functions. The learned

functions are represented by decision trees, but they

can also be re-represented as a set of if-then rules to

improve human readability. Those rules have been

extracted, codified in a programming language and

tested. The validation of the rules previously

generated took place using the hold-out validation.

In order to classify the rhythms, we used a

combination of rules: Cardiologic and Inferring

rules. The Cardiologic rules were obtained through

the translation of the arrhythmia descriptions found

in the specialized cardiologic literature (Farreras,

2001) and in parallel, we obtained the Inferring rules

by using techniques based on decision trees. Finally

we combined them and chose the best rules to detect

each rhythm. More details about the decision

support module can be found in (Rodriguez, 2003).

Data Manager Module

The main goal of this module is to efficiently

manage the restricted memory resources available in

the PDA, at least when compared to the great

capacity of ECG sensors to generate data.

It has knowledge about all the signals that are

being acquired and the stage of its processing. For

each packet, once the classification of the beats and

rhythm is done, the Data Manager decides how to

store each beat: in a regular file or in a database.

Normal ECGs are stored in compress files and the

anomalous ones are stored at the PDA database.

More details about the data manager module can be

found in (Rodriguez DOA, 2003).

Alarm Manager Module

This module receives the current heart rhythm

and associated parameters and decides whether to

generate an alarm. Not all the arrhythmias should be

sent in real time to cardiologists so that they can

confirm them and/or make their decisions: only

those considered very dangerous by them.

With the help of some cardiologists, we have

considered two groups, one for high-risk

arrhythmias, that is, arrhythmias that should be

notified to the hospital when they were detected by

the system and the other one for the moderate-risk

arrhythmias and normal rhythms that are stored but

not immediately notified.

Moreover, we have defined a personalized alarm

notification policy that allows deciding if an alarm is

sent or not depending on the user parameters. For

example: if the patient X presents a short ventricular

tachycardia (a high-risk arrhythmia), that alarm

would not be notified if the physician had previously

defined that, for patient X, only tachycardias longer

that thirty seconds should be notified. It has to be

noticed that an on-line monitoring system like this

would be useless if the cardiologists were bothered

with not really relevant arrhythmias very often.

Sender Module

This module is in charge of the communication

control between the PDA and the hospital. Hence, it

establish and maintain the connection in order to

send the alarm messages with the corresponding

ECG signal fragments and to answer to the report or

query solicitations that the hospital could make. A

standard is used to transmit medical data: HL7

(HL7, 2003) that is contained into the XML

message. An HL7 representation of clinical

documents is called Clinical Document Architecture

(CDA). The CDA is a document that specifies the

structure and semantics of a clinical document. It

can include text, image, sounds and other

multimedia content. When the message is received

by the hospital, the physician reads the report and

confirms the result obtained by MOLEC. Notice that

there are tools that can show the data represented in

HL7 messages to physicians.

Interface Module

The interface module is responsible for data

visualization and measurements display. The figure

5 shows a picture of the PDA-Holter. It provides a

friendly interface that draws the ECG signal as soon

as the current beat and rhythm types are obtained on-

line by the Decision Support Module.

3 IMPLEMENTATION DETAILS

The platform used for the implementation of the

PDA-Holter part of MOLEC has been the next PDA:

A WIRELESS APPLICATION THAT MONITORS ECG SIGNALS ON-LINE: ARCHITECTURE AND

PERFORMANCE

141

an iPaq 3970 which is a powerful device with a

400Mhz XScale processor, 64MB SDRAM and 48

MB Flash memory. Besides, it has a Linux support,

the Familiar Linux distribution (Handhelds 2003),

converting it in a complete embedded Linux system.

In figure 6, it can be observed that Linux has

been the chosen operating system. The external layer

of the figure shows the MOLEC modules that have

been explained in the previous section and in the

middle layer they can be seen the programming

languages used for the implementation of them.

We chiefly have used Java because it is: 1) an

object oriented language, 2) platform independent,

3) type safe; it provides 4) automatic memory

management, 5) built in threads, 6) synchronized

primitives and 7) exception handling, which makes

it proper for the development of a critical time

system like MOLEC is. Although many people

agree that the Java performance is not as good as the

one offered by other programming languages, this

happens only with interpreted Java. In our prototype,

we have compiled the Java source code with the

GNU compiler for Java (GNU, 2003), what

increased dramatically the processing performance.

For the signal preprocessing part, as this task

supposes several mathematical calculus, we chose

the Fortran and C languages.

For the implementation of the interface module,

we have used the SWT libraries (Eclipse, 2003)

because it has been possible to integrate them into

our PDA platform (Xscale processor and Linux

operating system), and to compile them with the

GNU compiler. Moreover, they have provided a

very acceptable processing performance (faster than

graphical libraries that usually come with Java

distributions like AWT and Swing).

For the wireless communications, two

technologies have been used: the Bluetooth

technology and the General Packet Radio Server

(GPRS). Bluetooth is a digital connection wireless

standard that can transmit data up to a rate of 1

Mbps; and GPRS is a wireless network that allows

sending and receiving data packages and its

bandwidth is up to 56 Kbps. In section 2.1, we

explain the difficulty to obtain the ECG sensors, so

for the tests we have performed, the PDA

communicates through Bluetooth with an ECG

sensor emulator placed in a computer device. The

ECG signals are taken from a recognized freely

distributed database, namely MIT-BIH Arrhythmia

database (MIT-BIH, 2003).

Data Manager

Alarm

Mana

Decison

support

Java

Sender

Linux

4 PERFORMANCE RESULTS

The main goal of our system is to monitor on-line

the ECG signal from people suffering from heart

arrhythmias. The technology proposed for the

system, PDAs and wireless communications,

imposes some restrictions that affect the design of

MOLEC.

On the one hand, working with wireless

communication technology is more expensive than

using wired communication technology. Therefore,

it is interesting to pay special attention to try to

minimize the cost of the wireless communications

and, at the same time, not to delay the notification of

serious heart anomalies to the hospital.

On the other hand, it is known that the most

powerful current PDAs, even with the latest

technological advances, are environments with

limited computing resources if compared to PCs.

Moreover, the processing tasks that a monitoring

system implies require a high computation cost: the

signal processing that obtains the sequence of beats,

the classification process of those beats and the

corresponding rhythms, and the visualization of the

ECG signal. Note that the ECG sensors generate

data very quickly. In our case, the data stored

correspond to a signal with a frequency of 360

samples per second what is equivalent to 21,600

samples/minute.

Hence, we focus on efficiency in order to prove

that a local processing of the ECG signal in a PDA

would not introduce too much latency in detection of

Figure 5: ECG visualization in MOLEC

Data Preprocessing

Fortran

Interface

Acquisition

Figure 6: PDA platform

ICEIS 2004 - SOFTWARE AGENTS AND INTERNET COMPUTING

142

eventual alarms, compared with a system where the

processing is made remotely.

The proposed architecture in section 3 is a

functional solution for an ECG monitoring.

However, it is also necessary a proper configuration

of the processing threads of the system in order to

obtain a system stable in time.

Therefore, it is essential to answer to the next

question: how often does the analysis process have

to be executed?, or, in other words, which is the

proper size of the “source package” provided by the

“ECG Signal Acquisition Module” that starts the

processing in the PDA?

In this section, we are going to present the

experiments that we have made with the goals of:

calculating the rate of the processing cycle that the

system can tolerate in order to not get overloaded,

thus the smallest rhythm detection delay (finding the

optimal processing rate); and of estimating the

latency of the alarm notification and the

communication costs with a medical monitoring

center.

The test results are compared with the results

obtained for the same parameters in a PC.

4.1 The optimal processing rate

Each time the ECG Signal Acquisition receives ECG

samples, the system must analyze them in order to

find arrhythmias, performing in this way an entire

processing cycle. The question we try to answer here

is how frequently we should perform this

processing, in other words, which is the processing

rate for the system.

On the one hand, as we have mentioned in

section 3, in order to identify arrhythmias, first we

have to detect the beats from the ECG signal. The

typical occurrence of the beats, in one minute, is

between 60 and 100, therefore, the entire processing

cycle (that means also the size of the ECG signal

package analyzed) should not be less than one

second since the probability to find a beat in such a

short time interval is really tiny and besides, the

algorithm of detecting the wave events is more

accurate with longer signals.

On the other hand, the smaller the cycle duration

is the faster the alarm detection could be.

Unfortunately the computation cost for each cycle

does not decrease proportionally to the cycle size

and the system can get overloaded. Moreover, this

cost differs from PDA to a normal PC since they

have different computation power.

Hence, in order to establish the optimal

processing rate we have tested the system

performance for processing cycles of one and two

seconds respectively. Both types of test have been

performed in the PDA and in the PC.

10 0

200

300

400

500

600

700

800

61 129 199 281 368 454 542 634

ECG adquisition time

ECG procesing time

PDA_1 PC_1

Figure 7: Processing rate of one

second

10 0

200

300

400

500

600

700

66 132 196 260 324 388 452 518 582 646

ECG adquision time

ECG procesing time

PDA-2 PC-2

Figure 8: Processing rate of two seconds

The figures 7 and 8 show four functions: PC-1,

PDA-1, PC-2 and PDA-2. Every point (x,y) of all

those functions indicates that the signal package

provided by the ECG Signal Acquisition at the

second x is processed by the system at the second y.

For PC-1 and PDA-1 functions, the entire processing

cycle is of 1 second, and for PC-2 and PDA-2

functions it is of 2 seconds. In PC-1 and PC-2, the

entire processing cycle is performed in the PC, and,

obviously PDA-1 and PDA-2 in the PDA.

As it can be observed in the figures, in both

cases the system running in the PC achieves a stable

state since the corresponding functions are very

close to the diagonal function (that would mean that

the signal packet received at second x is processed

by the system at second x). The stability comes from

the fact that the difference between the diagonal and

the PC-x functions does not grow along the time. In

other words, the system performs all the tasks before

A WIRELESS APPLICATION THAT MONITORS ECG SIGNALS ON-LINE: ARCHITECTURE AND

PERFORMANCE

143

the next signal package has been arrived. In the PDA

case, for processing cycles of one second, this

property is not achieved. Nevertheless, good results

are obtained for processing cycles of two seconds.

As we have explained before, the package size

has a direct influence on the rhythm delay detection,

and therefore, in the alarm detection. The average of

the time necessary to detect the rhythm for this type

of packages appears in figure 9.

Figure 9: Rhythm detection delay

For packages of one second the PC achieves an

average of 4.43 seconds in obtaining the rhythm,

meanwhile the PDA needs 10.3 seconds, but, as the

processing cannot be performed in real time, the

rhythm detection delay would grow if the

experiment duration were longer.

For packages of two seconds the PC obtains an

average of 5.2s to detect the rhythm meanwhile the

PDA needs approximate 6.66s to detect it.

Notice that we have also experimented with

signal packages of 3 seconds and seen that real-time

processing is also possible. But, as the rhythm delay

time is greater than with signal packages of 2

seconds, so we conclude that the entire ECG

analysis process should be performed in the PDA

every 2 seconds.

Finally, an explanation of the rhythm detection

delays obtained is because the detection algorithm

used needs the previous beat types and the next three

ones, in order to detect the rhythm for the current

beat.

4.2 Alarm notification: cost and

latency

The aim of this subsection is to compare the

MOLEC system, which only sends alarm signals to

the medical center (according to the Alarm Manager

Module policy described in section 3), with a system

that continuously sends the ECG signals picked up

from the sensors and detects the alarm in the medical

center. Supposing that a GPRS network is used for

communication, we present further the

communication costs for the alarm notification

during 30 minutes of monitoring.

For this test we used three ECG records: the 100

record that does not contain any alarm, so there is no

communication with the medical center; the 207

record that is from a patient with serious health

problems and contains five minutes of alarms; and

124 record that is from a typical user, so it contains

an average notifications amount. All the ECG

signals used have the same sampling frequency (360

samples/second). For the system that sends all the

signals we supposed that each sample has 2 bytes.

In the next figure it can be observed the amount

of data that the system would send in each case.

1296

40.3

96.1

200

400

600

800

1000

Monitor Center

100

124

207

Figure 10: Communication costs

A system, that does not make any processing and

compressing of the signal, would send

approximately 1296Kb for each 30 minutes which

means more than 2Mb/hour, meanwhile the

MOLEC-PDA-Holter, in the worst case would send

more than 100 times less. If no abnormalities are

detected then there is no communication with the

health center, as in the case of the record 100.

Therefore the amount of communication with the

health center is drastically reduced, and so the

communication costs.

Another variable that should be taken into

account is the delay between the time when the risk

episode starts and the moment when the health

center notices it.

The time needed for the MOLEC system to

notify an alarm is

notify

= t

rhythm detection

alarm compression

+ t

communication latency

In other words the notification delay depends on

the time needed to detect the rhythm in the PDA, the

time needed to compress the alarm message and the

latency that the GPRS network involves in order to

send it to the monitor center.

On the other hand, in the case of the systems that

continuously send ECG signals to the medical center

the notification delay would depend only on the

ICEIS 2004 - SOFTWARE AGENTS AND INTERNET COMPUTING

144

communication delay over the GPRS network and

the rhythm detection time in the medical center.

As it could be observed in the figure 9, the delay

of the rhythm detection, with our algorithm, is

greater in the PDA (around seven seconds) than in a

normal PC with only one user (around four seconds).

In a system with more users that continuously send

ECG signals the costs to obtain the same results

would be greater.

Moreover, a system that continuously sends

ECG signals to a monitor center would send many,

but small signal packages through the network, what

means, if the connection is stable, a constant latency

in the communication; meanwhile the MOLEC

system sends compressed alarm messages from time

to time but with a bigger amount which suppose a

bigger latency to send it.

Therefore, the notification latency is a few

seconds bigger in the MOLEC system but still

remains in a reasonable threshold giving the

possibility to the user to obtain medical assistance in

time.

5 CONCLUSIONS

In this paper we have presented the global

architecture of an innovative system called MOLEC

that allows an on-line monitoring of people suffering

from heart arrhythmias. Among the advantages of

that system are the following ones: 1) Promptness:

MOLEC detects anomalous rhythms, anywhere and

anytime, as soon as they are produced, and sends the

corresponding alarm to the hospital; and 2)

Efficiency: MOLEC optimizes the use of wireless

communications and PDA resources.

In order to achieve those advantages, we have

designed and performed some experiments that

consisted in calculating the rate of the processing

cycle that the system can tolerate in order to be

efficient, stable and the rhythm detection delay

minimal. That time has been 2 seconds in the case of

the PDAs. Special attention has also been paid in

minimizing the cost of the wireless communications

without increasing the delay time for the detected

serious heart anomalies. That can be achieved by

performing the ECG signal processing and rhythm

classification locally in the PDA and by sending

only alarms to the hospital.

REFERENCES

Bluetooth. 2003. www.bluetooth.com

Cardio Control.2003.

www.cardiocontrol.com/cardio.htm

Daja, N., Relgin, I., Reljin B., 2001. Telemonitoring in

Cardiology –ECG transmission by Mobile Phone.

Annals of the Academy of Studenica 4, 2001.

Despopoulos, A.., Silbernagl, S. 1994, Texto y Atlas de

fisiología. ISBN: 84-8174-040-3.

Dimitri Konstansas Val Jones, Rainer Hersog. 2003.

MobiHealth- innovative 2.5/3G mobile services and

applications for healthcare. Workshop on

Standardization in E-Health. Geneva, Italy.

Eclipse 2003.

http://www.eclipse.org/.

Farreras and Rozman, “Medicina interna”. Decimatercera

edición. Edición en CD-ROM. Sección 3. Cardiologia

pag 395 – 523. October, 2001.

GNU 2003.

http://gcc.gnu.org/java/

Handhelds 2003.

http://www.handhelds.org/.

Health Level 7 (HL7). 2003.

http://www.hl7.org/.

Jané, P., Blasi, A., García, J., Laguna, P. 1997. Evaluation

of an Automatic Threshold Based Detector of

Waveform Limits in Holter ECG with the QT

database”. Computers in Cardiology, vol. 24, pp. 295-

298.

Kunze, C., Gromann, U., Stork, W., Müller-Glaser,

K.D.,2002. Application of Ubiquitous Computing in

Personal Health Monitoring Systems. 36. annual

meeting of the German Society for Biomedical

Engineering.

Le Blanc, R., “Quantitative analysis of cardiac

arrhythmias.” CRC: Critical Review in Biomedical

engineeering, 14(1):1-43, 1986

MIT-BIH Database Distribution. 2003.

http://ecg.mit.edu/

Mitchell, T.M., “Machine Learning.” ISBN 0-07-042807-

7. Section 3: Decision tree learning. Pages 52-75.

Pan, J., Tompkin, W. J. 1985. A real-time QRS detection

algorithm". IEEE Trans. Biom. Eng. BME-32: 230-

236.

Rodríguez, J., Goñi A., Illarramendi, A. 2003. Classifying

ECG in an On-Line Monitoring System. Submitted for

Publication.

Rodríguez, J., Goñi A., Illarramendi, A. Capturing,

Analyzing and Managing ECG Sensors Data in

Handheld Devices. DOA 2003.

Sachpazidis 2002. @Home: A modular telemedicine

system. Mobile Computing in Medicine, Proceedings

of the 2. Workshop on mobile computing. Heidelberg,

Germany, 2002.

Ventracor Limited. 2003 http://www.ventracor.com

A WIRELESS APPLICATION THAT MONITORS ECG SIGNALS ON-LINE: ARCHITECTURE AND

PERFORMANCE

145