Sie sind auf Seite 1von 87

Communication Systems Group, Prof. Dr.

Burkhard Stiller

Mobile Healthcare on Android Devices

Sacha Gilgen Basel, Switzerland Student ID: 02-052-942


Supervisor: Andrei Vancea, Guilherme Machado Date of Submission: November 2, 2010 University of Zurich Department of Informatics (IFI) Binzmhlestrasse 14, CH-8050 Zrich, Switzerland

Diploma Thesis Communication Systems Group (CSG) Department of Informatics (IFI) University of Zurich Binzmhlestrasse 14, CH-8050 Zurich, Switzerland URL:

Die Fortschritte der j ungsten Zeit in den Bereichen kabelloser Sensoren und mobiler Kommunikation, erm oglichen neue Formen der Anwendung in der Gesundheitspege. Insbesondere die Verf ugbarkeit von kleinen, leichten und sehr sparsamen Sensoren, bieten neue M oglichkeiten einer kontinuierlichen Uberwachung menschlicher, biomedizinischer Daten und erm oglichen somit die Fr uherkennung eines Krankheitspotentials. Diese Bachelorarbeit stellt einen Prototypen der mobilen Gesundheitspege vor, der beabsichtigt, EKG-Daten von Patienten zu u berwachen. Das System besteht aus drei Elementen: einem tragbaren Sensor, der EKG-Daten am Patienten aufzeichnet; einem Mobiltelefon, das als Schnittstelle fungiert, indem es die vom Sensor erhaltenen Daten u bermittelt; und schliesslich einem Server, der u ber ein Anzeigemodul zur graphischen Darstellung u ugt. Basierend auf das angezeigte EKG, sind Arzte in der bermittelter EKG-Daten verf Lage einige grundlegende, medizinische Einsch atzungen f ur ihre Patienten zu machen.


Recent technological advances in wireless sensors and mobile communication enable new types of healthcare systems. Especially the availability of small, lightweight and ultra-low power sensors gives new possibilities for a continuously monitoring of human biomedical data and therefore allows an early detection of potential illness. This bachelor thesis presents a prototype mobile healthcare system intended to monitor ECG data from a patient. The system consists of three parts: a wearable sensor that records ECG data on a patient, a mobile phone that acts as a gateway by forwarding the data received from the sensor and nally a server containing a visualization module to graphically display the recorded ECG data. Based on the displayed ECG, doctors are able to make some basic medical diagnostics for their patients.



First of all, I would like to express my gratitude to Professor Burkhard Stiller for giving me the opportunity to write this bachelor thesis. Furthermore, special thanks go to my supervisors Andrei Vancea and Guilherme Machado for the time and eort they spent and for their precious advices. Finally, I would like to thank my mother and father for their assistance, encouragement and love during my studies.



Zusammenfassung Abstract Acknowledgments 1 Introduction 1.1 1.2 1.3 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Description of Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

i iii v 1 1 2 2 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6 7 8

Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 Related Work 2.1 Electrocardiography 2.1.1 2.1.2 2.1.3 2.2

The Activity of the Heart . . . . . . . . . . . . . . . . . . . . . . . 3-Lead Electrocardiography . . . . . . . . . . . . . . . . . . . . . . Interpretation of an Electrocardiogram . . . . . . . . . . . . . . . .

Shimmer Sensor Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.2.1 2.2.2 2.2.3 Shimmer Key Principles . . . . . . . . . . . . . . . . . . . . . . . . 10 Shimmer Platform Design . . . . . . . . . . . . . . . . . . . . . . . 11 Shimmer Key Features . . . . . . . . . . . . . . . . . . . . . . . . . 12


Google Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.1 2.3.2 Android Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Android Components . . . . . . . . . . . . . . . . . . . . . . . . . . 15 vii

viii 2.4

CONTENTS Ruby on Rails Web Framework . . . . . . . . . . . . . . . . . . . . . . . . 17 2.4.1 2.4.2 Ruby on Rails Architecture . . . . . . . . . . . . . . . . . . . . . . 17 Ruby on Rails Components . . . . . . . . . . . . . . . . . . . . . . 19 21

3 Design 3.1

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.1.1 3.1.2 3.1.3 The Sensor Component . . . . . . . . . . . . . . . . . . . . . . . . . 22 The Mobile Component . . . . . . . . . . . . . . . . . . . . . . . . 23 The Server Component . . . . . . . . . . . . . . . . . . . . . . . . . 24


Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.2.1 3.2.2 3.2.3 The Sensor Component . . . . . . . . . . . . . . . . . . . . . . . . . 26 The Mobile Component . . . . . . . . . . . . . . . . . . . . . . . . 27 The Server Component: . . . . . . . . . . . . . . . . . . . . . . . . 32 39

4 Implementation 4.1

Mobile Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.1.1 4.1.2 4.1.3 Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . . 39 The Bluetooth Service Component . . . . . . . . . . . . . . . . . . 46 The Network Service Component . . . . . . . . . . . . . . . . . . . 52


Server Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.2.1 4.2.2 Storage of ECG data . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Vizualization of ECG data . . . . . . . . . . . . . . . . . . . . . . . 54 57 61 63 67 67

5 Future Work 6 Summary and Conclusions Bibliography Abbreviations List of Figures

CONTENTS List of Tables A Installation Guidelines

ix 70 73

A.1 Mobile Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 A.2 Server Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 B Contents of the CD 75


Chapter 1 Introduction
This bachelor thesis introduces a prototype mobile healthcare system, aimed to monitor ECG data of a patient. First, the motivation of the work is presented, followed by a broad description of the mobile healthcare system developed.



Recent technological advances in wearable sensor networks, integrated circuits and wireless communication allow the design of lightweight, low power consuming sensors at low-cost [50]. Together with advances in mobile communication, new opportunities open up for developing healthcare systems, which remotely monitor biomedical signals of patients. Especially the continous or even sporadic recording of biomedical signals, such as electrocardiography, are critical for the advancement of diagnosis as well as treatment of cardiovascular deseases [51]. For example the continous recording of the electrocardiogram by a wearable sensor could provide a realistic view on the heart condition of a patient during normal daily routines. Current practices of monitoring the electrocardiogram at hospital fail to generate such a realistic report of the heart rythm [51]. Further automated analysis of recorded biomedical data supporting doctors in their daily interpretation of data and allowing the development of warning systems are thinkable. This would bring several benets, as to help decrease healthcare costs by increasing health observability, collaboration of doctors and doctor-to-patient eciency [56]. Moreover, continious monitoring will increase early detection of abnormal health conditions and diseases, providing a great potential to improve patients quality of life [55].This marks the beginning of a new trend for future healthcare systems which includes the evolution from disease centric to patient centric care, the delocalization of care from hospitals to home, and the focus on prevention rather than on reaction of already existing disorders [53] [54]. New generation of mobile phones will have an important impact for the development of such healthcare systems, as they seamlessly intergrate a wide variety of networks (3G, Bluetooth, wireless LAN and GSM) and thus provide the opportunity to transmit recorded biomedical data to a central server in a hospital. The continuous monitoring of biomedical 1


data is then not bound to the home environment but could be extended outside of these boundaries. Besides the broad communication capabilities, mobile phones support further opportunities like the monitoring of a patients location using GPS or the display of biomedical data. Especially the monitoring of location data could provide a context to the recorded biomedical data. For example the location data could be used to gather further information about the environment where the patient lives and thereby supporting the analysis of patient health conditions. The goal of this thesis is to design and implement a prototype mobile healthcare system, monitoring the electrocardiography signals of patients. Thereby the focus lies on sending the recorded data seamlessly from an wearable sensor over a mobile phone to a central server. Although the intended mobile healthcare system should only record electrocardiography signals, it has to be designed to support the recording of further biomedical signals. The nal developed mobile healthcare system should allow basic medical assessment of patients provided by doctors.


Description of Work

The objective of this work is to design and implement a prototype mobile healthcare system that uses Android mobile devices. The system should consist of three parts: A sensor application, a mobile application and a centralized server application. The sensor application should record raw biomedical data in real time and transmit this data wirelessly to a connected Android mobile device. The mobile application should then store the received biomedical data into a database and forward it to a centralized server after some initial processing. This way the mobile device acts as a gateway between the sensor and the server for the recorded data. Finally the server stores the biomedical data into a database. Furthermore the server should consist of two modules: a visualization module to graphically display the biomedical data and an analyzing module that implements a simple algorithm to perform basic assessments of patients. While the prototype system shall only record and store ECG data, the architecture of the overall system should be implemented in a manner to be exible enough in order to support various types of biomedical and environmental data.


Thesis Outline

This bachelor thesis is structured as follow: the next chapter forms the background for the further explanations by introducing electrocardiography and describing the technologies used. The third chapter describes the design decisions and architecture of the prototype mobile healthcare system with respect to the dened requirements. This is followed by chapter four which describes the implementation of the previously dened design and


architecture. In chapter ve possible future work for the healcare system are presented. Finally the sixth chapter will conclude with a brief summary of the work done.


Chapter 2 Related Work

This chapter aims to present the fundamentals of electrocardiography before describing the main technologies used later to implement the prototype healthcare system.



The electrocardiogram (ECG) is an interpretation of the electrical activity of the heart over time captured by placing electrodes on the surface of the body [1]. The signal recorded, is graphically displayed in a two dimensional graph, where the height represents the measured electrical activity in millivolts and the width the interval of time in seconds. Figure 2.1 shows a typical ECG waveform.

Figure 2.1: Typical ECG waveform To understand how and what an ECG records, it is important to have a essential knowledge of how the heart works. For this reason the next section is devoted to describe the basic functionality of the heart, before describing the ECG waveform and its interpretation in detail. 5



The Activity of the Heart

The heart is a muscle which has the purpose to pump blood throughout our body. For this, the heart consists of various chambers; a right atrium, right ventricle, left atrium and left ventricle, as shown in Figure 2.2 [3]. These two sides of the heart work together to pump blood through our body system. The right side of the heart delivers deoxigenated blood from the body to the lungs, whereas the left side of the heart delivers oxygenated blood from the lungs to the body [2].

Figure 2.2: Sectioned view of the heart A pumping cycle begins, when deoxygenated blood from the body returns to ll the right atrium of the heart. When the right atrium is full, it contracts and pushes the blood into the right ventricle. Now, when the right ventricle is lled, it contracts and pumps the blood further into the lungs. The oxygenated blood from the lungs is then returned to the left atrium of the heart. The left atrium contracts and pumps the blood into the left ventricle. This occurs at the same time as a new contraction is taking place in the right atrium, lling the right ventricle with blood. Finally the left ventricle contracts and sends the blood to the rest of the body. At the same time the right ventricle pumps blood into the lungs. After the contraction of the ventricles, a new cycle begins.

Figure 2.3: Electrical conduction system of the heart


For the described contraction of the heart, an electrical impulse is necessary. This electrical impulse is generated by the Sinoatrial Node (SA node) and propagates through the conduction system of the heart, shown in Figure 2.3 [1] . First the electrical impulse spreads from the SA node throught the muscle tissue of the right and left atrium and follows an internodal pathway directly to the atrioventricular node (AV node ), where it is naturally delayed. This stimulates the artrial muscle cells, causing both atria to contract in unison and ll the ventricles with blood. Especially the delay, caused by the AV node is important, because it allows to ll the ventricle with blood by atrial contraction, before the ventricles contract itself. After the AV node, the impulse continuous down to the Bundle of His, where the conduction system branches out to a right and left bundle branch and nally terminates in tiny bres, known as Purkinje Fibres. This Purkinje Fibres conduct the electrical impulse throughout the ventricular, stimulating the muscle cells and causing a contraction of the right and left ventricles in unison. At the beginning of this cycle a resting heart is polarized, which means that the heart cells have a negative charge [2]. As a stimulus occurs, the cells changes its charge to positive. This is called depolarization and causes the heart muscle bres to shorten and consequently the heart muscle to contract. During this contraction the cells regains slowly a negative charge, as the electrical impulse is moving down along the conduction system, causing the heart muscle to relax. This process is known as repolarization. The potential change, which occurs during depolarization and repolarisation, is exactly what can be measured at the skin surface by electrodes [2]. This recorded electrical activity can then be displayed in a two dimensional graph known as electrocardiogram.


3-Lead Electrocardiography

As mentioned, the ECG works by detecting the electrical changes on the skin, caused when the heart muscle depolarises. This is done by placing pairs of electrodes on either side of the heart. The output of a pair of electrodes is known as lead and is said to look at the heart from a specic perspective [1]. These leads are also called bipolar leads, as they measure the voltage dierence between two electrodes [2]. Based on the number of leads recorded, several types of ECGs are dierentiated. For example 3-lead ECG, 5-lead ECG and 12-lead ECG. These types of ECGs mainly dierentiates from each other by the precision and accuracy of their recordings.A 12-lead ECG for example records more leads than a 3-lead ECG and therefore has a broader view on the heart. Consecutively the 3-lead ECG will be described in more detail, as it was used in this project. The 3-lead ECG is based on the most basic form of electrodes placement, known as Einthovens triangle [52]. Thereby the electrodes are placed as follow: one on the right arm (RA), one on the left arm (LA) and the third one representing the left leg (LL) is situated below the hearts apex. The electrodes then form the leads: LA + RA (Lead I), LA + LL (Lead II) and RA + LL (Lead III). Figure 2.4 illustrates the placement of the electrodes and the three leads they form [35]. The leads are described by convention as follow [36]:


Figure 2.4: Standard 3-Lead ECG based on Einthovens Triangle Lead 1 (LA-RA): measures the potential dierence between the right arm electrode and the left arm electrode. Lead 2 (LA-LL): measures the potential dierence between the right arm electrode and left leg electrode. Lead 3 (RA-LL): measures the potential dierence between the left arm electrode and left leg electrode.

This 3-lead system provides three dierent views, able to monitor multiple regions of the heart [35] and consequently yields to three dierent signals. Table 2.1 summarizes the chambers, viewed by the 3-lead ECG [35]. Lead Lead I Lead II Lead III Views Lateral Inferior Inferior Heart Chambers Left ventricle, left atrium Left and right ventricle Right and left ventricle

Table 2.1: Heart chambers viewed by the 3-lead ECG


Interpretation of an Electrocardiogram

The recorded ECG signal shows a series of waves, that relate to the electrical impulses, which occur during each beat of the heart. These waves are labeled with successive letters of the alphabet P, Q, R, S, T, and U, as shown in Figure 2.5 [1]. When it comes to the interpretation of an ECG signal, the attention turns to the segment and intervals, also illustrated in Figure 2.5. The most important intervals and segments, followed by their description, are summarized in table 2.2 [1] [35] [37].


Figure 2.5: Normal ECG waveform

Feature RR interval

P waves PR segment

PR interval

QRS Complex

ST Segment T wave QT interval

Description Represents the interval between an R wave an the next R wave and is the inverse of the heart rate. A normal resting heart rate lies between 50 and 100 beats per minute. The P wave represents the depolarization of the right and left atria. The PR segment coincides with the electrical conduction from the AV node through the Bundle of His, toward the Purkinje Fibers. Hence the PR segment corresponds to the time between the end of artrial depolarization, to the begin of ventricular depolarization. Represents the time measured between the beginning of the P wave to the beginning of the QRS complex. The PR interval reects the time an electrical impulse takes to travel from the SA node through the atria and the AV node down to the Purkinje Fibres. The QRS complex represents the rapid depolarization of the two ventricles. Because the ventricles have a larger muscle mass than the atria, the QRS complex has a much larger amplitude than the P-wave. The ST segment lies between the QRS complex and T wave and represents the period, when the ventricles are depolarized. The T wave corresponds to the rapid ventricular repolarization. The QT interval represents the complete ventricular cycle, starting with the depolarization and ending with the repolarization. Table 2.2: Segments and intervals of an ECG wave

Based on the rythm of the recorded ECG and the patterns of the segments and intervals in a ECG waveform, abnormalities can be detected and a dignose can be given.




Shimmer Sensor Platform

Shimmer [22] - which stands for Sensing Health with Intelligence, Modularity, Mobility and Experimental Reusability- is a wearable sensor platform intended to provide researchers an extensible and exible system that can be utilized to rapidly develop prototype research applications [33]. The Shimmer platform was originally developed by the Intel Digital Health Group in 2006 [25]. Later the platform was commercialized by Shimmer Research, a division of the Realtime Technology Ltd., following a worldwide licensing agreement with Intel. Shimmer Research designs, develops and manufactures a full range of wireless sensors and claims to be the leading provider of wearable wireless sensors in the world, shipping to over 40 countries worldwide [17]. Figure 2.6 shows a Shimmer sensor.

Figure 2.6: Shimmer Sensor


Shimmer Key Principles

The Shimmer platform was developed with the goal to allow biomedical researchers to focus on their research instead of the development of applications during the lifecycle of their research project [33]. The key princibles that underline the Shimmer wearable sensor platform, as stated on her website, are [23]: Flexible: Shimmer is extremly exible due to the fact that it can be programmed to meet exact data capture and tranfer requirements. Moreover Shimmer can be adapted for dierent sensing purposes due to its modular expansions described later. Highly Congurable: Shimmer provides a suite of technologies to oer compability with a wide variety of system technologies including other sensors. For example the platform oers Bluetooth or 802.15.4 radio for the communication with other devices and the instant transmission of recorded biomedical signals. Furthermore a microSD card is included, allowing a local storage of recorded data. Open Source: All code and rmware is actively maintained and available online at Sourceforge [34]. Raw Data: Shimmer provides raw data, giving the researchers and developers full control over the interpretation and analysis of the sensed data.




Shimmer Platform Design

The Shimmer platform consists of a baseboard which provides the sensor computational, data storage, communications and daughterboard connection capabilities [31]. Figure 2.7 [26] gives a brief overview of the sensors technical specication. The core capabilities of the Shimmer baseboard can be extended via a wide range of daughterboards committed to provide wearable kinematic, biophysical, and ambient wireless sensing capabilities[33]. For this a connector is provided, that allows the user to connect daughterboards to the baseboard. The extension capabilities make a exible and thus valuable platform out of Shimmer. Table 2.3 gives an overview of the currently available extensions dautherboards.

Figure 2.7: Overview of Shimmers technical specications

Kinematic sensing Gyroscope Magnetometer Accelerometer

Biophysical sensing Electrocardiograph (ECG) Electromyograph (EMG) Galvanic Skin Response (GSR)

Ambient sensing Passive Infrared (PIR) Motion Temperature Light

Table 2.3: Overview of Shimmer extension daughterboards




Shimmer Key Features

The main requirements a wearable sensor should comply in a healthcare environment are certainly, low power consumption, light weight, small form factor, low power communication capabilities and modularity [30]. These are exactly the features the Shimmer platform exhibits as consecutively described.

Low Power Consumption The Shimmer baseboard is equipped with a MSP430 MCU [27] and other hardware to minimize power consumption. Especially the MCU from Texas Instrument is known for its low power consumption during periods of inactivity and has a proven history for biomedical sensing platforms [31]. Further the Shimmer rmware was optimized with focus on lowering the on-time of all hardware subsystems on the sensor hardware platform and thus extends operation life of the sensor [32].

Small Form Factor and Light Weight With an enclosure size of 53mm x 32mm x 15mm and a weight of 22 gramms the Shimmer sensor is perfectly appropriate for sensing biomedical data as a wearable mobile sensor.

Communication Capabilities One of the key features of Shimmer is certainly its ability to communicate wirelessly with other sensor and devices. For this the Shimmer platform provides two modules: the IEEE 802.15.4 radio module and the Bluetooth radio module. The Bluetooth module contains the full Version 2 Bluetooth Protocol Stack guaranteeing the compatibility with a wide range of other Bluetooth devices like mobile phones.

Firmware The rmware of Shimmer is primarily developed by using TinyOS [28], a light-weight event-driven operating system, especially designed for sensor network nodes that have very limited resources [32]. This rmware provides the low-level capabilities to control the sensor functions like: local processing of the sensed data, local storage of the data and communication of sensed data to a higher-level application for advanced signal processing, display and data persistence [32]. All Shimmer rmware is therby available online at Sourceforge [34]. The operating system TinyOS, is responsible for task scheduling, radio communication, time, I/O processing and has a very small footprint, which makes it suitable for sensor devices [31]. TinyOS is completely written in nesC [29], an extension of the programming



language C. An important concept of nesC is the separation of construction and composition [29]. An application is built out of serveral components, which are assembled to form the whole program. Components are interconnected through their interfaces which species the components behaviour [29]. This basic concept allows the development of exchangable and reusable components. Proven components for a specic purpose can be reused in other applications, hence lowering the development time. The fact that the Shimmer platform is completely open source and provides a rich set of valuable features as mentioned above, was the reason to use it for the development of the system described in this bachelor thesis. In addition of that it was commercially available and was easily to be purchased.


Google Android

Android is an open-source software stack for mobile devices provided by Google and the Open Handset Alliance (OHA) [7]. The Open Handset Alliance is a group of approximately 78 technology and mobile companies which put their eorts together with the goal to accelerate innovation in mobile and oer better mobile experience to the customer [4]. Particulary the group members are committed to openess as stated on their website[5]: Each member of the Open Handset Alliance is strongly committed to greater openness in the mobile ecosystem. Increased openness will enable everyone in our industry to innovate more rapidly and respond better to consumers demands. The following section presents the Android architecture before describing some important concepts of the Android SDK.


Android Architecture

The Android system architecture consists of four layers and several components as shown in gure 2.8 [7]. Each layer uses the services provided by the layers below. The reminder of this section will briey describe each layer, beginning with the Linux kernel. Linux Kernel Android is built on an open Linux kernel that includes core system services such as security, memory management, process management, network stack, and drivers. Further the kernel acts as an abstraction layer between the hardware and the software stack and can be extended to incorporate new cutting edge technologies [7]. For example new drivers can be supplied by third-parties developers to incorporate new communication technologies like Long Term Evolution (LTE). Using a Linux kernel as an hardware abstraction layer, allows Android to be ported to a wide variety of platforms (e.g. tables, netbooks) in the future [13].



Figure 2.8: Android System Architecture Android Runtime On top of the Linux kernel is the Android runtime, including the Dalvinik virtual machine and the core Java libraries. Dalvnik is a custom Java virtual machine (VM), that was designed to optimize memory management and hardware resource in a mobile environment [6]. Furthermore the runtime machine was developed to accomodate the requirement that an device should run several VM eciently [7]. Each application in Android is written in Java and runs on its own process, with its own instance of the Dalvnik virtual machine [7]. Libraries The shared native libraries are all written in C or C++ and used by dierent components of the Android system. The functionalities provided by the native libraries are made available through the Android application framework [7]. Application Framework Above the native libraries and the runtime, there is the application framework layer used to build applications. Developers have access to the same framework APIs used by the core applications. All Android applications are created equal. Further the application architecture is designed to simplify the reuse of components [7]: each application is able to publish its capabilities and any other application can use this functionalities. The most important parts of the framework are: Views Content Providers Resource Manager Notication Manager Activity Manager



Applications All applications are written using the Java programming language. The application layer includes a set of core applications preinstalled on every Android device including: email, maps, contacts, web browser, phone dialer, calendar, text message and Android market. For the development of applications a Software Development Kit (SDK) is provided with the necessary tools and APIs.


Android Components

As mentioned above an Android application can make use of functionalities of other applications. In order for this to work, the system should provide the ability to start an application process when any part of it is needed and instantiate the relevant Java objects for that part [9]. Consequently Android applications do not have a single entry point. Instead an application is made up of components that the system can instatiate individually and run as needed [9]. Android provides four essential types of components:

Activities An activity presents a visual user interface for a specic action the user can undertake [9]. For example an address book application might have an activity that shows a list of all available contacts and a second one that displays the details of the chosen contact. Furthermore an activity might consist of several views like buttons, text elds, scroll bars, menu items, check boxes and more. Views are where the activitys interaction with the user takes place [9]. The contact detail activity mentioned above, might for example consist of several text elds displaying contact information of the user like: email, phone numbers, addresses and buttons to perform actions related to the contact informations. When the user tabs on a button beside a phone number this initiates the action for starting another activity to write a text message. An application can consist of one or several activities. What purpose these activities serves and how many activities an application consist of, depends on the application and its design [9]. Each activity within an application is treated independent of the others.

Services A service is an application component without user interface that runs in the background for an indenite period of time [9]. They are perfect to perform ongoing or regular processing even when the applications activities are not active, invisible or closed. Android supports two types of Services: Local Service: are not accessible from other applications and thus generally used to support the application that is hosting the Service [15]. Remote Service: are accessible from other applications through a well dened interface using the Android Interface Denition Language (AIDL). These kind of services are used for inter-process communication [15].



Services are launched in the applications main thread, like all other components of the application (e.g. activities) [9]. Once a service is started it will live until it is stopped explicitely or terminated by the run times resource management [14]. The only reason Android will stop a started service is to provide additional resources for a forground component (usually an active activity) [14]. When that happens the service will be restarted automatically as soon as resources becomes available again. So because services have the second highest priority assigned by Android, they are less likely to be terminated by the run times resource management. A typical example of a service taken from the Android developers website [7], is a media player playing songs from a play list. The player application might consist of one or more activities that allow an user to choose songs and to play them. Though the music playback itself would not be handled by an activity, because the music has to keep playing even after the user leaves the player. To seamlessly keep the music going, the media player activity could start a service that runs in the background until explicitly stopped. Android itself includes several services that can be used. For example the location manager, media controller or a notication manager.

Broadcast Receivers Broadcast receivers are components intended to receive and react on broadcast events [9]. In Android many broadcasts originate from the system code such as broadcasts announcing network availability, battery status or incoming mails. But an application can also initiate a broadcast itself, informing other applications about an ocurred event. Broadcast receivers are important components to enable the creation of event-driven applications founded on internal, system or even third-party-application events [14].

Intent The three components mentioned above can be activated using intents. Intents are ansynchronous messages passed between components within an application or between applications and provide a way to turn a collection of independent components into a interconnected system. Activities, services and broadcast receivers are activated by intents. An intent is nothing else than an object that holds the content of the message. For activities and services an intent names the action being requested and holds an URI of the data to act on among other things [7]. For example, it may include a request for an activity to display a phone dialer. For broadcast receivers, the intent declares the event (or action) that occured. For example, it might announce that a new WLAN network has been detected. Using intents to pass actions is an fundamental Android design principle which allows the decoupling of components. Furthermore the decoupling of components allows the seamless replacement of application elements and provides the basis for extending an applications capabilities [14].

2.4. RUBY ON RAILS WEB FRAMEWORK Content Providers


Content providers are used to share the applications data with other applications on the device. For this, the content provider extends the ContentProvider base class, and implements a set of methods to enable other applications to retrieve and store data of the type it controls [7]. An Application will then use a ContentResolver object to communicate and cooperate with the corresponding provider to retrieve and store data. Like with broadcast receivers, there are also native content providers that expose databases like the media store or the contact information. Content providers are the only way to share data across applications.


Ruby on Rails Web Framework

Ruby on Rails (RoR) [16] is an open-source web framework written in the Ruby [18] programming language. It is designed to make the development of web applications easier and more productive by making the assumption that there is a best way to do things[19]. Therefore RoR is often mentioned to be an opinonated sofware [19]. RoR applications are built upon two solid principles [19]: Dont Repeat Yourself (DRY): Implies that repeating the code over and over again is a bad practice and should be avoided. Convention over Conguration (CoC): Compared to other web frameworks RoR tries to minimize the needed conguration by making assumption about what a developer wants to do and how he is going to do it. Developers following the convention of RoR only need to specify unconventional aspects of the application.


Ruby on Rails Architecture

Ruby on Rails uses the Model-View-Controller (MVC) architecture pattern to structure the application as shown in gure 2.9 [20]. This allows the isolation of the business logic from the user interface and clarify where dierent types of codes belong to, keeping the code DRY [19]. Consecutively each layer of the MVC architecture is described briey. Models: Are used for managing the rules of interactions with a corresponding database table and represent the information of the application. Usually one table in the database corresponds to a model in the application [19]. Views: Represents the user interface of the application and handles the job of providing data to the web browser. The views consist of HTML or XML les with embedded Ruby code [19]. Controllers: Provide the connection between models and views and are responsible for processing the incoming HTTP requests, interrogating the models for data and passig the data to the views for presentation [19].



Figure 2.9: Ruby on Rails MVC Architecture

Besides the MVC pattern, RoR uses the Representational State Transfer (REST) architecture style [17] by organizing the application around resources and standard HTTP verbs. Each resource in a RoR application is represented by an URL which identies that resource. This allows to transfer the representations of the state of a resource between system components [19]. When a HTTP request comes in, RoR analyzes the requested URI and routes the request to the appropriate controller [21]. For example in the URI /patient/4 the patient designates the controller called patients and the 4 the database ID of a particular patient. How the request are routed is dened in a conguration le called routes.rb. A resourceful route dened in routes.db provides the mapping between HTTP verbs, URLs and a corresponding action (also called method) in the controller. For each action a correspoding view can be dened, if necessary. Following the naming conventions of RoR, these views will have the same name as the actions. By dening the entry resources :patients in the routing le, Ruby on Rails will create the routes shown in table 2.4. The developer is not bound to these standard routes. RoR also allows the denition of routes to custom actions in the controller. The outgoing representation of a resource in RoR does not have to be an HTML page. RoR allows to send dierent representations of a resource based on the clients request. Which representation is sent, depends on the URI or the value provided in the HTTP header [21]. For example, the URI /patients/1.html will send back an HTML page, whereas the URI /patients/1.xml will send back the patients data represented in an XML le. To handle dierent representation for a specic action on a resource, RoR provides the respond to method. This should be illustrated by an example: A controller called patients exists with the action show. This action should be able to serve two dierent representations of a patient: an HTML representation and an XML representation. The code of the action show is shown in gure 2.10. Accordingly an HTML le called show.html.erb and an XML le called show.xml.builder are dened. If the client request an XML representation then the respond to method will return an XML le with the name corresponding to the action request. In this case

2.4. RUBY ON RAILS WEB FRAMEWORK Usage Display a list of patients Return an HTML form for creating a new patient Create a new patient Display data of a specic patient Return an HTML form for editing a patient Update data of a specic patient Delete a specic patient HTTP verb GET GET Path /patients /patients/new Method View index index.html.erb new new.html.erb



/patients /patients/:id /patients/:id/edit

create show edit

show.html.erb edit.html.erb


/patients/:id /patients/:id

update destroy

Table 2.4: Standard routing in Ruby on Rails

Figure 2.10: Example of action show show.xml.builder. But if the client request an HTML representation then the respond to method will return the HTML le show.html.erb.


Ruby on Rails Components

Ruby on Rails is composed of many components serving dierent purposes. Subsequently the most important components are described briey. Action Controller: Manages the controllers in a RoR application. It processes the incoming requests to a RoR application, extracts the parameters of a request and sends them to the intended action dened in the corresponding controller [19]. Action Controller provides many services like: Session management Template rendering Redirect management


CHAPTER 2. RELATED WORK Action View: Manages the views in a RoR application. A view can be an HTML or an XML output template. Action View is responsible for rendering these templates. Active Record: Provides database independence, CRUD functionality, advanced nding capabilities and the ability to relate models to one another [19]. For this, active record connects the data models and database table by turning rows from the database into objects that can be manipulated. Database management systems currently supported by active record are: SQLite, MySQL, PostgreSQL and more sophisticated ones like Oracle and Microsoft SQL Server. Active Resource: Provides a framework for managing the connection between business objects and RESTful web services by mapping web-based resources to local objects with CRUD semantics [19].

Chapter 3 Design
This chapter describes the design of the mobile healthcare system. In the rst section the context and the global requirements of the intended system are presented. Based on the dened global requirements, more ne grained requirements for the dierent components of the system will be derived. These requirements form the base for the design and architecture decisions, presented in the second section.



Before specifying the requirements, the context of the overall system has to be elaborated. This means, the system embedded in its environement. Figure 3.1 illustrates the context of the system.

Figure 3.1: Mobile healthcare system context 21



The patients use the Shimmer sensor to record their ECG signal. The recorded data will be sent to a mobile phone, which acts as a gateway by forwarding the data to a central server. Through a web interface the patients and their doctors will be able to see the recorded ECG signal. Doctors can then diagnose the ECG signal of their patients and give some recommendations. Additionally the mobile phone could monitor the position of the patient, using GPS and send it together with the ECG data to the server. This would allow, to relate the ECG signal to the position of the patient and derive the pace he is moving at. Furthermore the server could be connected over a well dened interface, to the hospital system, to retrieve additional information about the patient. As shown in gure 3.1, the last two scenarios are outside of the system context and were not considered during the development of the mobile healthcare system. Based on the context described, the global system requirements in table 3.1 were dened. No. R1 R2 Requirement End-to-End system Flexible architecture Description Recorded biomedical data shall seamlessly be transmitted from the sensor through a mobile phone to a central server The architecture should be exible enough, in order to support dierent types of medical or environmental data.

Table 3.1: Overall system requirements In the follwing section rened requirements for each component of the system are specied taking into account the previously dened global requirements.


The Sensor Component

This section presents the requirements specied for the sensor component. Table 3.2 summarizes the dened requirements. No. R3 R4 R5 Requirement Record ECG data Transmit ECG data Remote control of sensor Description The sensor records raw ECG data in real-time. The sensor transmits the recorded data wirelessly to the mobile application. It should be possible to start and stop the recording of data, by sending corresponding commands wirelessly to the sensor. A dened protocol should be used to send recorded data. Further the protocol should support the transmission of dierent types of biomedical data.


Use of dened protocol

Table 3.2: Requirements for the sensor component




The Mobile Component

Use cases have been specied for the mobile application, to get a sense of the behavior of the application. Figure 3.2 gives an overview of the use cases dened.

Figure 3.2: Use cases for the mobile application The user starts the mobile application and authenticates with the server. This will allow the mobile application to periodically send data to the server. Furthermore the user can connect the mobile phone with a sensor. After connecting the devices, the mobile application starts to periodically request biomedical data from the sensor. The received data will then be stored in a database. Table 3.3 lists all the requirements specied for the mobile application. These requirements are partly grounded on the use cases, illustrated previously. No. R7 R8 R9 R10 Requirement Authenticate with server Establish connection to sensor Periodically request biomedical data Receiving biomedical data Description The user should be able to authenticate with the server. The user should be able to establish a Bluetooth connection with the sensor and later to disconnect. The mobile application should periodically request biomedical data from the sensor. The mobile application should be able to support the protocol, dened by the sensor for the transmission of biomedical data. Thereby the mobile application should be able to receive dierent types of biomedical and environmental data.

24 R12 Store biomedical data

CHAPTER 3. DESIGN The mobile application should store the received biomedical data in a database. This is needed, as there could not be guaranteed that a network is available to forward the data. The database should be designed in a way to be exible enough, in order to support dierent types of biomedical or environmental data. The mobile application should periodically send stored biomedical data to the server, using a HTTP-based protocol. Biomedical data sent to the server should be deleted in the database to guarantee, that enough memory space is always available at any time. The mobile application should be able to receive and send biomedical data, even if the application is not active on the mobile phone.


Extensible database


Periodically send biomedical data Delete biomedical data



Background tasks

Table 3.3: Requirements for the mobile component


The Server Component

The following use cases were specied to describe the behavior of the web server application. The use cases are illustrated in Figure 3.3.

Figure 3.3: Use cases for the web server application



The web server application will be used by two types of users: patients and doctors. The doctor registers to the web application and receives a conrmation mail, to activate his account. After activation, the doctor can log in and invite patients by providing an email address. The patient will receive an invitation mail including an URL, pointing the web site for registration. After successful registration and activation of the account, the user can access the web application. From this point on, the patient can use the sensor and the mobile phone to send recorded ECG data to the server as described previously. Further the patient will be added to the list of patients of the doctor. The doctor is now able to see the ECG data of the patient and write a diagnosis in form of a comment. This will be displayed to the user, which is able to ask questions about the diagnosis. Some sort of basic asynchronous communication will then be possible between the patient and the doctor. Based on the use cases presented, the following requirements in table 3.4 were specied. R17 R18 Authentication Authorization The web application should include an authentication system and handling session management. The web application should include a simple authorization system, allowing the user only to access the ressources, they are allowed to. User should be able to edit their personal data. The web server application should be able to receive biomedical data sent, using an HTTP-based Protocol The web server application should be able to store the biomedical data, received by the mobile application The web server application should contain a visualization module, to graphically display the stored ECG data of a patient. The web server application should contain a module, allowing basic medical assessment of patients. The database should be designed in a way, to be exible enough in order to support dierent types of medical or environmental data The user interface of the web server application should be designed in a way, to be easily extended with new services.

R19 R20 R20 R22

Edit personal data Receive biomedical data Store biomedical data Display ECG

R23 R24

ECG Assessment Extensible database


Extensible user interface

Table 3.4: Requirements for the web server application





In section 3.1 the requirements for the mobile healthcare application were specied. Based on these requirements, the architecture and design decision presented in this section were made. Figure 3.4 illustrates an overview of the overall system architecture and thereby used technologies.

Figure 3.4: System architecture of the mobile healthcare system

The Shimmer sensor sends the recorded ECG data over Bluetooth to an Android mobile phone. The received data will then be stored in a SQLite database and forwarded to the server, either by using the mobile network 3G or WLAN. A Ruby on Rails web application running on an Apache server will receive the recorded data and store it in a MySQL database. For all communications with the RoR web application the Hypertext Transfer Protocol Secure (HTTPS) is used to ensure an encrypted communication and secure identication of the web server. With the encryption of the data, protection is given against eavesdroppers and man-in-the-middle attacks. Subsequently the architecture and design decisions for each component of the mobile healthcare application will be presented.


The Sensor Component

For the sensor component, an already existing application was choosen [39] which was initially developed to be used with BioMobius. BioMobius is a platform, provided by TRIL (Technology Research for indepedend living), a research collaboration between Intel Coporation, GE Healthcare and a number of Irish academic partners [38]. Briey explained the BioMobious platform is a software development environment, intended to rapidly develop technology solutions for biomedical research[40].The platform can be used together with the Shimmer platform. All BioMobius compatible Shimmer applications are available on SourceForge in the tinyos-1.x/contrib/handhelds/apps/BioMOBIUS/ folder.



The application called ECG was chosen, because it fully satised all requirements specied preliminarily: record raw ECG data. send recorded data of a Bluetooth connection. allows to control the recording remotely by sending corresponding start and stop commands. provide an extensible protocol regarding the type of biomedical data to be sent. It is worth noting that the copyright notice [39] of the application explicitly allows the redistribution and the modication of the binary source code and therefore the application could be used for this project.


The Mobile Component

Because todays mobile phones integrate a wide range of wireless technologies like Bluetooth, WLAN and 3G, the main purpose of the mobile phone will be, to act as gateway forwarding data, received from the sensor, to the central server. Further as stated in the requirements it is important that the mobile phone can full these tasks, even if the application is not active. This means that the application should run two background tasks; one responsible to periodically request and receive recorded data from the sensor and the other task responsible to periodically send biomedical data to the server. These tasks form the two central components of the application architecture presented in gure 3.5.

Figure 3.5: System architecture of the mobile healthcare system



As illustrated in gure 3.5 the application is built on top of the Android framework using dierent Android libraries. The core libraries used are: the Bluetooth library, SQLite library, Network library and the HTTP library. The Application itself consist of dierent components briey described consecutively: Graphical User Interface: is responsible for the interaction with the user. Bluetooth Service: is responsible to setup an ongoing Bluetooth connection to a remote Shimmer sensor and to periodically request and receive ECG data from the sensor. Network Service: is responsible to periodically send recorded data to the server and correspondingly delete sent data from the database. Database Adapter: forms the abstraction layer to the underlying database and thus responsible for the interaction with the database. Network Adapter: is the abstraction layer to the underlying network communication. The network adapter is responsible to check for network availability (3G or WLAN) and to perform the HTTP requests to the server. Application: this component provides supporting services to the other components mentioned above. Looking from an other point of view, the mobile application consist of packages. Each package provides a certain capability of the application. These packages can be related to the components of the architecture mentioned previously. By looking on these packages a more ne grained view of the mobile application is provided. Table 3.5 presents all packages dened, their description and their relation to the architecture components introduced previously. Package gui Description contains all activities which form the graphical user interface of the application. bluetooth service contains a class implementing a local Android service, which is responsible to setup an ongoing Bluetooth connection to the Shimmer sensor. Further it controls the process of receiving, parsing and storing of biomedical data. network service consist of one class implementing a local Android service, responsible to periodically send biomedical data to the server. Therefore this class is responsible for the process of retrieving data, to send it to the server and to delete sent data from the database. database contains classes, which implement the services of the database adapter component. Component Graphical User Interface Bluetooth Service

Network Service

Database Adapter

3.2. ARCHITECTURE network parser implements the network adapter of the architecture this package is part of the application component and includes all parsers needed to parse packets sent from the sensor and to parse HTTP messages received from the server. will be extensively used by the application to send received biomedical data from one class to another class in a structured way. Therefore it provides a well dened message format for records. contains classes providing support for the core functionalities of the application. For example this package contains a class providing the service to calculate an 16bit crcchecksum. This checksum is needed to check, if a received packet of the sensor is erroneous or not. Network Adapter Application






Table 3.5: Package structure of the mobile phone application

Communication The Shimmer sensor and the Android mobile application communicate, by setting up a standard Bluetooth connection. For the communication between the two devices a dened protocol is used. Recorded biomedical data on the sensor will be sent using the packet format adopted from the sensor application. Figure 3.6 shows the packet format used for ECG data.

Figure 3.6: Packet format for ECG and accelerometer data

30 The elds of the ECG packet are dened as follow: BOF: binary value that marks the begin of the packet.


Sensor ID: contains the identication number of the sensor used. Data Type: a number indicating the content of the payload. Based on the data type the receiving device knows what data to expect in the payload. For example: ECG = 255 EMG = 254 GRS = 253 Sequence Number: used to check, if the packets are received in order. Timestamp: indicating the time, the record has been taken. Primarily used to calculate the time interval between two consecutive recorded values. Length: indicates the length of the payload. ECG-LALL: recorded value for Lead 2 (see section 2.2.2) ECG-RALL: recorded value for Lead 3 (see section 2.2.2) CRC: checksum to check if the packet is erroneous. EOF: binary value that marks the end of the packet The content of the packet elds contain binary data. Further the packet could have a variable payload length, thus supporting dierent types of recorded biomedical data. This allows to full the requirement, that the protocol should be extensible regarding the data recorded by the sensor. For example the payload of the accelerometer packet shown in Figure 3.6 was extended to be able to send the values of each recorded axis.

Database The mobile phone will store the recorded data in a SQLite database [41]. This is needed because it cannot be assumed that there will always be a network available to forward the biomedical data to the server. Before describing how the database schema was designed, two important terms should be introduced: Record: A record corresponds to what the sensor records in a specic point in time. In other words: a packet send by the sensor. Trace: A trace is a set of records, acquired in a certain period of time. In other words: a set of packets.



When designing a database schema it is important to think about how the database would be used. The database would primarily be used to: store records of dierent types. This corresponds to the specied requirement R13 (see section 3.1.2): the database should be designed in a way to be exible enough in order to support dierent types of biomedical data retrieve a trace recorded in a specic period of time. retrieve all records currently not send to the database. delete a single record or a single trace. With these requirements in mind, the database schema in Figure 3.7 was dened.

Figure 3.7: Android mobile database schema

The basic idea of the database schema design, was to adopt the structure of the packet format introduced previously. This means, that the database consist of a records table storing data common to all records and other tables, each intended to store the recorded values of a specic payload type. The records table contains the following columns: id: primary key of the records table. trace id: identier of a trace. Allows to lter the records table by trace. trace timestamp: timestamp when the trace has been recorded. Allows to lter the records table to get traces recorded whithin a certain period of time (e.g a day)


CHAPTER 3. DESIGN record timestamp: correspond to the timestamp of the packet header. record time interval: is the interval between current record timestamp and the previously received record timestamp. payload type: includes the name of the table, where the payload values are stored. payload id: a foreign key pointing to the row in the payload table, containing the recorded values. send: marks, if the record has already be sent to the server or not. 0 - not sent 1 - sent

The columns payload type and payload id are used to get the right payload values belonging to a record. By separating the records table from the tables containing the payload values, the database can be easily extended to store dierent payload types. An example should illustrate this: For an ECG packet the value of the header elds will be stored in the corresponding columns of the records table and the payload values in a table called ecgs with the columns lead 1, lead 2 and lead 3. Likewise an accelerometer packet will be stored. But the payload values of the packet will be stored in another table called accelerometers.


The Server Component:

The Ruby on Rails framework was chosen to develop the web application. The main reason why RoR was used, can be summarized as follow: RoR puts convention over conguration [19]. By following the conventions of RoR, the framework takes a lot of work common for each web application, allowing the developer to concentrate on the important task. RoR gives a structure how a web application should be organized. This has two main advantages. First the developer gets familiar quickly with the RoR framework, accelerating the development of the application. Secondly other developers who want to extend the application later, quickly get an overview of the application. RoR web application can be easily extended by plugins for common functionalities, like authorization and authentication. This is especially an advantage for the development of a prototype web application. By using plugins for common functionalities of a web application, the developer can concentrate on the specic and important functions. Furthermore, many plugins are widely used and therefore reliable and robust.



The architecture of the web application follows the Model-View-Controller architecture pattern, implied by the RoR framwork. Figure 3.8 illustrates the main controllers and models of the application.

Figure 3.8: Architecture of the Ruby on Rails web application

For each table in the database a corresponding model and controller has been dened. Furthermore the architecture contains additional models and controllers, needed to full specic tasks. The controllers are repsonsible for interrogating the models to get the data needed for the view and include the logic of the application. Table 3.6 gives an overview of the controller developed and describes their purpose.

34 Controller users user sessions

CHAPTER 3. DESIGN Description This controller is responsible for the registration of a new user and activation of the previously registered account. The user session controller is responsible for the login and logout of users and the session management. If a user log into the web application by providing his credentials, a new session is created. For leaving the web application the user will logout and the ongoing session will be destroyed. Responsible to store records, received by the Android mobile application using the corresponding record model. Responsible to list all available ECG traces of a patient and show the ECG signal for lead 1, lead 2 and lead 3 of the trace chosen. Further it allows to comment an ECG trace. To provide these functionalities, the ecg controller uses the record and ecg model. These two controllers allows a patient/doctor to edit or update his personal data. The relationships controller displays a list of all relationships between patients and doctors. For example doctors will get a list of all their patients and correspondingly patients will get a list of all their doctors. These two controllers are responsible to add, edit, update or delete addresses and phones. The password reset controller creates and resets passwords, using the user model. This controller provides a list of all ecg traces available for a particular patient. This conroller is only accessible by a doctor. If a doctor chooses a trace to be displayed, the controller issues an HTTP request to the doctor patient ecgs controller. The HTTP request contains the user ID and trace ID chosen be the doctor. Shows the ECG signal for lead 1, lead 2 and lead 3 of the chosen trace. This controller can only be accessed by the doctor. Further the doctor can only see the ECG traces of his patients. This controller is also responsible to store the comments written by a doctor. For this the record comments controller is used. The application controller provides services, used over the hole web application. For example, the controller consist of a method that returns user ID of the user holding the session.

records ecgs

patients & doctors relationships

addresses & phones password resets doctor patients

doctor patient ecgs


Table 3.6: Overwiew of the controllers developed for the web application

Some of the controllers presented in table 3.6 use functionalities of RoR plugins that were added to the web application. The used plugins are described briey in table 3.7.

3.2. ARCHITECTURE Plugin Authlogic

35 Description Authlogic [44] is an authentication system for RoR. Basically it handles the hole session management for the web application. By using Authlogic, the registration, login, logout, reset password and account activation functionalities of the web application, were implemented. Declarative Authorization [45] is an authorization system for RoR. The main feature of this plugin is that the authorization rules are declared in a central conguration le, using a domain specic language (DSL). This allows to increase the development and maintanance eciency, because the authorization rule are not spread over the code. Further the plugin allows to dene rules on different levels of the Model-View-Controller architecture. For the web application, two roles have been dened: patient and doctor. Patients are only allowed to access the data belonging to them. The same apply for doctor but additionally they can also access the data of the patient associated to them. Therefore they are enabled to access the ECG of their patient. SSL-Requirement [43] provides a declarative way to dene that certain actions of the web application should only be accessed using SSL. If these actions are accessed without SSL, the user is redirected to an non-SSL requiring page of the web application. This will be the login page.

Declarative Authorization


Table 3.7: Overview of plugins used for the web application

Web Services RoR uses the REST architecture style by organizing web applications around resources and standard HTTP verbs. Each resource is thereby represented by an URL which identies that resource. This pattern was adopted for the communication between the mobile application an the RoR web application. Figure 3.9 gives an overview of how the communication is designed.



Figure 3.9: Design of the communication between mobile application and web application

In the Android mobile phone application there will be primarily two Android components that want to issue a request: activities and services. For example a activity will request some data from the server to display these to the user or send data, provided by the user, to the server. A service, like the network service, will primarily send data to the server. To accomplish this, the components can use the network adapter. The network adapter is capable of issuing dierent HTTP request like: POST and GET. The encapsulation of the task to send HTTP requests and receive HTTP responses in a central component allows to extend the mobile application by further activities and services. To send a request, an Android component will provide the following information to the network adapter:

The URL for the intended resource on the web application and data if it is a POST request.

The network adapter will then issue the HTTP request to the indicated URL, using the Apache HTTP library, provided by the Android framework. Based on the URL the RoR framework will route the received HTTP request to the appropriate controller. The controller will then interrogate the models, to provide data requested or/and store the data provided, depending what the client requested. An HTTP response is then sent back to the client by the controller. The network adapter will receive the HTTP response and send it to the corresponding component, which issued the request. The communication design presented in gure 3.9 is really exible. For example, if a new web service should be provided, the web application will be extended by a new controller and model (if needed). The controller will then implement the actions allowed for the new service. On the mobile side, the application can be extended by a new component, which ask the network adapter to issue an HTTP request to the new service, by providing the right URL.

3.2. ARCHITECTURE Database


For the database on the server side, MySQL [42] was chosen over SQLite as database management system. The main reason for this, was that MySQL provides the possibility to dene foreign keys whereas SQLite does not. With the denition of foreign keys, some further consistency conditions can be dened on the database layer. The database schema of the web application is illustrated in Figure 3.10. For storing biomedical data, the database schema of the mobile phone has been adopted. The schema was then extended by other tables, to support the dierent functionalities of the web application, described previously in the requirements (see section 3.1.3). Primarily this extension should allow users to authenticate with the application. For this to work, a users table was dened to store common information about a user, like: title, rst name, last name, email. To allow the user to authenticate with the web application the users table contains additionally the following columns: encrypted password, password salt, presistence token, perishable token and status. All these columns were implied by the Authlogic plugin to implement the authentication system. Beside the authentication of users, the web application should support dierent types of users, namely: patients and doctors. Doctors and patients will have dierent authorization, regarding what they can do on the web application. Therefore, a user will either have the role of a patient or the role of a doctor. Which authority a user has, will be stored in the column role of the users table. This column is implied by the plugin Declarative Authorization, which provides the authorization system. To allow the storage of specic data for a patient or doctor, two further tables were created, a patients table and a doctors table. Now a doctor can have several patients and similarily, a patient can have several doctors. For this, the relationships table was dened storing all associations between patients and doctors. Addresses of a user are stored in the addresses table. This was done to accomodate the fact, that a user can have several addresses. For example a home address, a work address and the address of the summer residence. Therefore a one to many relationship was dened between the users table and the addresses table. The same applies of course for the phone numbers, stored in the phones table. Finally the database schema includes a comments table. This table allows, to store comments belonging to a certain trace. Comments are written either by a patient or a doctor. This is why the comments table is associated to the users table in addition to the association with the records table. An association between the comments table and the doctor or the patient table would not make sense. As illustrated in the gure, each comment will belong to a particular user and is written for a particular trace. A user can thereby write several comments.



Figure 3.10: Database schema of the web application database

Chapter 4 Implementation
The previous chapter gave a broad overview of the design and architecture of the mobile healthcare system. In this chapter the implementation details of the main functionalities are covered. Thereby some more ne grained design decisions will be presented. Further only the mobile component an the server component are considered, as for the sensor component an already existing application was used.


Mobile Application

This section rst describes how the graphical user interface of the Android mobile application was implemented. After that the implementation of the two essential services of the application are described.


Graphical User Interface

The mobile application consists of three activities which actually form the user interface of the application. These activities are: MainView, BluetoothView and LoginView. Figure 4.1 shows the user interface of each activity.

Figure 4.1: Mobile application user interface 39



The MainView is the activity shown to the user when the application is launched. From this activity the other two activities will be started. An activity presents the visual user interface to the user . The activitys user interface is dened by a hierarchy of view and view group nodes. Views are basic visual interface elements like buttons, text elds, check boxes, menu items and so on [11]. View groups are containters for views. They are used to form a compound element made up of several views [11]. Figure 4.2 shows the composition of an activity.

Figure 4.2: Composition of an activity

On the Android platform there are two possible ways to design the user interface of an activity: specify the layout and views programmatically or use a declarative way, by dening the layout and views in an XML le. Both ways were used to implement the activities of the mobile application. The declarative way was used to specify the layout and views of the user interface and the programmatically way was used to dynamically change the user interface. Subsequently the activities and their implementation are described.

The MainView Activity The MainView consists of an information panel and a list of menu items as shown in Figure 4.3. The information panel is destined to display messages to the user. For example a welcome message or in future, an alarm messages indicating that a critical health condition were recognized. Below the information panel dierent sections are displayed containing menu items. A section groups all menu items which belong together. Each menu item in a section corresponds to a specic action the user can undertake. Currently the MainView consists of two sections: Account Management, with the menu item Login and Sensor Management with the menu item Connect. The user interface described so far, is specied in an XML le called main.xml. As shown in Figure 4.3 all views are placed on a ScrollView. The basic idea to use a ScrollView was to be able to extend the user interface by additional sections. If the user interface overlaps



Figure 4.3: The activity MainView and its decomposition in view components

the screen, by adding further sections, the user can simply scroll down to see the hidden parts. Consequently it is possible to give the user an overview of all actions available on the entry user interface of the application. To extend the user interface by additional sections, two view components have to be added on top of an additional LinearLayout : a TextView for the title and a SectionItem for the menu item of a section. The SectionItem is a custom view dened in a separated le called section item.xml and referenced from the main.xml le. It consists of three views: two ButtonViews to display an image and a TextView describing the action the menu item performs. Figure 4.4 shows how a section is specied in the main.xml le.

Figure 4.4: Implementation of an section in main.xml



As illustrated in Figure 4.4 all views have an ID and a visibilty attribute. The ID is used to address a view programmatically from the activity. This concept allows to dynamically change the user interface or respond to specic events (e.g. button pressed) of a view. Furthermore, the attribute values can be changed. For example to hide a view the value of the visibility attribute could be programmatically set to gone. MainView consists of two menu items: login and connect. If the user tabs on the login item the LoginView is shown to the user. Similarly if the user tabs the connect item the BluetoothView is shown. These two buttons will dynamically change depending on whether the user is logged in or not. For example, if the user has succesfully logged in, the login menu item dissappears and instead a logout menu item is shown. To allow this change, the visibility attribute of the login SectionItem is programmatically set to gone and correspondingly the visibility attribute of the logout SectionItem is set to visible.

The LoginView Activity The LoginView provides a form, where the user can put his credentials for authentication with the web application. When the user tabs on the login button the data is sent as an HTTP request to the server. The server responds to the request with an HTTP response containing the user ID. After successful authentication the network service is started.

Figure 4.5: Sequence diagram of the authentication process

Many classes are involved to send an HTTP request and parse the corresponding HTTP response. The sequence diagram of Figure 4.5 illustrates which classes are involved and the interactions between them. LoginView calls the method performPost(url, params, handler) of the HTTPRequestManager to send an HTTP request. The HTTPRequestManager is a central class which sends all HTTP requests of the application. For sending an HTTP request to the indicated URL the HTTPRequestManager uses the HTTPClient class, provided by the Android



framework. This is done by calling the execute(httpMethod,responseHandler) method of the HTTPClient, providing an HTTP method (e.g. POST or GET) and a response handler as arguments. The corresponding received HTTP response is sent from the HTTPClient to the HTTPRequestManager using the response handler previously registered. The HTTPRequestManager forwards the HTTP response by using the handler of LoginView. The LoginView class will then check the HTTP response status. For a status code 200 (OK), indicating that everything is ne, the XML le within the entity body of the HTTP response is parsed. If the status code is greater than 200, indicating that something went wrong, a dialog is shown to the user containing the HTTP response reason. To parse an XML document the SAXParser of the Android API is used. First a XMLReader object is requested by calling the getXMLReader() method of the SAXParser class. Then a handler is set for the XMLReader by calling the setContentHandler() method. The handler passed is called LoginHandler and species how the XML document is parsed. After dening the handler, LoginView starts the parser by calling the method parse(xml) of the XMLReader. The parsed data can then be accessed by calling getParsedData() of the LoginHandler. This will return an instance of the LoginParsedData class. The LoginParsedData class holds the parsed data of the received XML le and makes it accessible to LoginView through the method getUserID(). This process described so far, works similarly for all components (activity or service) in the Android application, that wants to send an HTTP POST request and receives an HTTP response with an XML le. Thereby each component denes its own ParseHandler (e.g. ParseLoginHandler ) and ParsedData (e.g. ParsedLoginData ) class. The ParsedHandler denes what happens when the XMLParser encounters an XML element or character in the XML le. Figure 4.6 shows how the ParseHandler is implemented for the LoginView activity.

Figure 4.6: Class:



When the XMLParser starts parsing the XML document it calls the startDocument() method of the ParseHandler. The ParseHandler then creates a new instance of the ParsedLoginData class to store the data extracted from the XML le. For each start and end element of the XML le the XMLParser calls the corresponding startElement() and endElement() method. These methods are used to monitor at which element the parser currently is. For this the value of the corresponding variables are set to true (start of element) or false (end of element). Finally, when the XMLParser encounters a character, it calls the characters() method of the ParseHandler. The ParseHandler checks if the parser is at the element where it expects data, by checking the variable of that element. If the variable is true, the data within the element is stored. For this the ParseData class denes corresponding setter and getter (to retrieve the data later) methods. Figure 4.7 shows the XML le for which the ParseLoginHandler and ParsedLoginData were dened. An HTTP Response with the status code 200 contains an XML le formatted as illustrated in Figure 4.7.

Figure 4.7: Example of an XML le received from the server

The element user session indicates that the XML le was created by the web application resource (or controller) called user sessions and the user element shows that the data was extracted from the user model. The user id element contains the identier of the user. This user ID is stored by LoginView using the SharedPreferences class of the Android framework. SharedPreferences provides a general framework that allows to save and retrieve persistent key-value pairs of primitive data types [8]. The stored data will persist even if the application is killed. SharedPreferences is directly accessible from any class within the application and therefore the perfect place to store the user ID. The user ID is used by other classes to make further requests to the web application. With this user ID the controller knows which user made the request.

The BluetoothView Activity The BluetoothView activity allows the user to enable or disable Bluetooth on the mobile phone. Without this functionality the user has to leave the application, go to the settings of the phone, enable Bluetooth and come back to the application. Furthermore the user can connect to a Shimmer sensor by tabbing on the Connect button. This will display an Android dialog which contains a list of already paired Bluetooth devices. If the Shimmer sensor is not listed in the dialog, the user can scan for further devices by tabbing on the scan button. New discovered devices appear in the dialog. Finally the user connects to the desired sensor by tabbing on the corresponding list item. This will show a new



Android dialog, indicating, that the mobile phone is connecting to the Shimmer sensor. After sucessfull connection setup, the remote device name and the remote devices MACaddress is shown. Now the user interface contains a Disconnect button instead of a Connect button. Figure 4.8 gives an overview of the BluetoothView user interface.

Figure 4.8: User Interface of the BluetoothView activity

The user interface of BluetoothView dynamically changes depending on the Bluetooth and connection state. Therefore the mobile phone can be in one of the following three global states:

Bluetooth enabled & connected Bluetooth enabled & disconnecting Bluetooth enabled & disconnected Bluetooth disabled & connecting Bluetooth disabled & disconnected

How the BluetoothView changes its user interface, is implemented in the BluetoothView activity. Figure 4.9 gives an overview of the dynamical behavior implemented for the BluetoothView. It shows which action induce a state transition and which view element will appear or disappear. Beside this it shows when the Bluetooth service is started. To know the current connection state of the mobile phone, the BluetoothView has to register to the broadcast receiver provided by the BluetoothService class. The actual Bluetooth state can be known by asking the BluetoothAdapter class provided by the Android Bluetooth API. Each time the BluetoothView activity is started, the Bluetooth state and then the actual connection state of the mobile phone is checked. Depending on these states the user interface is build.



Figure 4.9: Overview of the dynamic behavior of BluetoothView


The Bluetooth Service Component

The Bluetooth service component of the mobile application is responsible to setup an ongoing connection to the Shimmer sensor. Once connected, the Bluetooth service will periodically request ECG data from the sensor. The implementation of the Bluetooth service component is located in the bluetooth service package and consist of the following classes shown within the class diagram of Figure 4.10.

Figure 4.10: Package: bluetooth service



The BluetoothService class extends the Service class of the Android API, and therefore behaves like a local Android service. Android services are used for ongoing background tasks. An important feature that services provide is, that they continue to run even if the application is not active. As the BluetoothService is responsible to handle an ongoing Bluetooth connection, it makes perfectly sense to implement it as an Android service. As mentioned before, the BluetoothView starts the BluetoothService. For this the BluetoothView calls the startService(Intent) method by providing an intent as parameter. The intent holds the address of the sensor to connect with. The connection is then setup using two inner classes of BluetoothService : ConnectThread: The ConnectThread is responsible to setup the connection to the Bluetooth device. This is done by rst creating a BluetoothSocket and then using that socket to connect with the sensor. After connection setup the ConnectThread starts the ConnectedThread by calling the connected() method of the BluetoothService. Thereby the created socket is passed as argument. ConnectedThread: The ConnectedThread manages the connection to the sensor. That is, it uses the socket provided by the ConnectedThread to listen for incoming data and to send data. Further this class contains the logic, to lter out packets of the incoming data stream. To lter for packets the ConnectedThread uses three elds: the BOF eld indicating the beginning of the packet, the length eld indicating the payload length of the packet and the EOF eld indicating the end of the packet. By using the length eld, packets with dierent payload size can be received. This is important because dierent biomedical data, recorded by a Shimmer sensor, will have packets with distinct payload size. Furthermore the CRC eld, containing the checksum of the packet, is used to check for erroneous packets. Packets where the CRC fails are discarded. After the connection is setup, the BluetoothService is able to control the sensor by sending corresponding commands: a start transmission command signals the sensor to start the recording and transmission of ECG data. Accordingly a stop transmission command indicates the sensor to stop the recording and transmission of ECG data. With these two control commands the BluetoothService is able to periodically record ECG data. The recording of ECG data in dened intervals will allow to drain the battery consumption due to the Bluetooth connection. Figure 4.11 illustrates the periodical recording of ECG data on a timeline.

Figure 4.11: Periodical recording intervals



The transmission of ECG data is started directly after the connection is setup. Simultaneously a timer is set for the duration of record interval (see Figure 4.11). After the timer has expired the BluetoothService stops the transmission and starts another timer for the duration of request interval (see Figure 4.11). Currently the record interval time is set to 2 minutes and the request interval time is set to 30 minutes.

Figure 4.12: Process initiated by receiving ECG data

The start of recording ECG data, marks the beginning of a process executed on the mobile phone. This process is illustrated in gure 4.12 and consists of receiving, parsing and storing the recorded data. When receiving a packet stream from the sensor, the individual packets are ltered out by the Bluetooth service and send to a parser. The parser is then responsible to extract the elds of a packet and store it in a record object. A record object provides the ability to send the received data in a structured way from one component to another. After parsing a packet the parser sends the created record object to the record handler. The record handler species the further path of the packet. As illustrated in Figure 4.12 the record object could be send directly to the database adapter or via the processing and analysing component. Consequently the process is really exible concerning the path a record object can take. This allows to extend and change the process as needed. Further the process was implemented to support dierent kinds of biomedical data sent by the sensor. This will be shown subsequently by describing each component of the proccess.

The Record Object Process Component A record object is responsible to store the elds of a packet and is used to tranfer the packet data from one component to another. The implementation of a record object is located in the record package and consists of the classes illustrated in 4.13.



Figure 4.13: Package: record

The design of a record object is similar to the database schema illustrated in Figure 4.13. The abstract RecordObject class stores the header part of a packet and the subclass, like ECGRecord, stores the payload part of a packet. This design is very exible regarding the support of dierent biomedical data. It can be easily extended to support new types of biomedical data. For this, only a new subclass has to be created which implements the storage of the specic payload part of a packet. The same design principle of the record object is used by the other components of the process.

The Parser Process Component The parser receives a packet from the Bluetooth service and is responsible to parse the packet. Thereby a new record object is created and sent to the record handler. Figure 4.14 shows the implementation of the parser, located in the package parser. The BluetoothService sends a Java Vector, holding the elds of a received packet, to the parser. This is done by using the parser() method of a Parser subclass. To choose the right parser, BluetoothService rst interrogates the ParserFactory class by calling the method getParser(type). The parameter given to the method is the value of the data type eld in the packet. The data type indicates what type of biomedical data the packet payload contains. Based on the type, the ParserFactory returns an instace of the right Parser subclass. For example the ParserFactory returns an instace of the ECGParser subclass, if the data type is ECG. After receiving an instance of the right parser, the BluetoothService sends the packet to the parser (e.g. ECGPaser ). The ECGParser will



Figure 4.14: Package: parser then use the abstract Parser class to retrieve the header elds of the received packet. After retrieving the payload part of the packet the ECGParser will instatiate an ECGObject by providing all elds to the constructor of the class. The ECGObject is then returned to the BluetoothService. BluetoothService will then call the onNewRecord() method of the RecordHandler registered. Again by separating common tasks from specic tasks using the inheritence concept the design remains exible. This means that new parsers can be added to support the parsing additional biomedical data.

The Record Handler Process Component The record handler denes what happens next with the record object. Figure 4.15 illustrates how the record handler was designed.

Figure 4.15: Class diagram of the record handler process component

The main purpose of the RecordHandler class is to allow dierent components (e.g. activities) to get biomedical data from the BluetoothService. The components will then be able to decide, what happens next with the received data. For this a component registers a handler, which implements the RecordHandler interface, to the BluetoothService. This



is done by using the registerRecordHandler() method of the BluetoothService class. The method will take a RecordHandler as argument and store this handler in a list. Each time the BluetoothService receives a RecordObject from the parser it will call the method onNewRecord() of all registered handlers. Thereby the RecordObject is passed as argument. How the RecordObject will be used, is implemented in the RecordHandler the components registered. In the current implementation the BluetoothView activity registers the storeRecordHandler to the BluetoothService. The storeRecordHandler species that each record will be stored to the database using the database adapter component. Therefore the record handler component allows to specify more than one path at the same time for the process illustrated in Figure 4.12. The Database Adapter Process Component The database adapter component is responsible for storing biomedical data. The implementation of the database adapter is located in the package database. Figure 4.16 illustrates how the database adapter was designed.

Figure 4.16: Package: database A class that wants to store a record object, has rst to call the method open() of the DBAdapter class for reading and writing data. Then the class can call the storeRecord() method by passing the RecordObject (e.g ECGObject ) as an argument. This method will then store the header data and consult a HashMap to know which class is responsible to store the payload. For this the HashMap maps the name of each implemented RecordObject subclass to the right SerializationAdapter instance. For an ECGObject the HashMap will return an instance of the ECGAdapter, which is responsible to store the payload values in the ECG table of the database. This is done by calling the storePayload() method of the ECGAdapter. After storing the RecordObject, the database has to be closed explicitly by the class which opened the database. The design of the database adapter allows to add support for additional biomedical data by dening a new class that implements the SerializationAdapter interface. This class has then to be added to the HashMap of the DBAdapter class.




The Network Service Component

Similarly with the Bluetooth service the network service is implemented as a local Android service. It is responsible to periodically send recorded data to the server. For this it retrieves the records currently not sent from the database. The network service is started by the LoginView activity after sucessfull authentication of the user. The implementation of the network service is located in the package network service. Figure 4.17 gives an overview of how the network service is implemented.

Figure 4.17: Package: network service For periodically sending records to the server the NetworkService class uses a timer. When the timer is elapsed the NetworkService checks the database for records to send. This is done by calling the method retrieveRecordsToSend(). The method returns a Java Vector of RecordObject s. Each RecordObject will then be sent individually using the HTTPRequestManager. This is done in a similar way as described for the LoginView activity in section 4.1.1. If the RecordObject is successfully stored on the server side, an XML le containing the record ID of the stored RecordObject is sent back to the mobile phone. The NetworkService uses the record ID to delete the corresponding record in the database. For this the method deleteRecord() of the DBAdapter is called passing the record ID as argument. After sending the data to the server the timer is reset. The data of a RecordObject is sent to the server as URL encoded parameters following the naming convention of RoR. Each data item is enclosed by the name of the model, which is responsible to store the data on the server side. For example: record[trace id, value] indicates that the record model is responsible to store the trace ID. Similarly ecg[lead 1, value] indicates that the ecg model stores the value of lead 1. This will become clearer in section 4.2.1, when describing the storage of ECG data on the server side. By calling the method getParamsToSend() of the ECGObject the ECG data is returned in the correct format to the NetworkService. This data is then sent as an HTTP POST request to the URL http://domain-name/records.xml. The URL indicates that the action create of the records controller handles the request.


Server Application

The server features two importants parts, worth to take a closer look to their implementation. One part is the storage of the received ECG data and the other part is the



visualization of the ECG data. Other implementation details of the web application are left, because they follow the convention and structure set by the RoR framework and therefore are self-explanatory.


Storage of ECG data

Records sent by the NetworkService are made available to the create action of the records controller by the ActionController class of the RoR framework. The records controller stores the data using the ecg and record model. Figure 4.18 gives an overview of how this is done.

Figure 4.18: Records controller

The HTTP request initially issued by the NetworkService is routed by RoR to the create action of the records controller, using the URL specied. The ActionController class is thereby responsible to extract the URL encoded parameters of the HTTP request and make it available to the controllers create action. By calling the method params[:ecg] of the ActionController class all parameters previously named with ecg are provided. Similary the method params[:record] returns all parameters named record. This is why in the NetworkService the data was formatted like this: record[trace id, value], ecg[lead 1, value]. By calling the method new(params[:ecg]) of the ECG class (representing the ecg model), a new record in the ecgs table of the database is created. Correspondingly the method build record(params[:record]) of the ECG class, will create a new record in the records table of the database. This is possible, because a RoR association was dened between the record model and the ecg model. After the data was successfully stored, the controller returns an XML le by calling the method xml{}. This method will then render the corresponding XML le located in the views/records folder. By following the naming convention of RoR for the XML le, the RoR framework knows that the create.xml.builder le belongs to the create action of the records controller.




Vizualization of ECG data

For the visualization of the ECG data the open source JavaScript library Raphael [48] was used. Raphael is an adapter for creating vector graphics for the web. For this, it follows the SVG W3C recommendations [49] as base to create graphics. This means every created graphical object is also a DOM object and therefore a JavaScript handler can be attached to them. For the visualization of graphs, Raphael provides a plugin called gRaphael. This plugin was used to display the ECG signal for each recorded lead of a trace. Figure 4.19 shows the visualized ECG signal of lead 1, lead 2, lead 3.

Figure 4.19: ECG signal of lead 1, lead 2 and lead 3 displayed by the web application



Three RoR components are responsible for the visualization of a patients ECG trace. Figure 4.20 illustrates which components are involved and the interactions between them.

Figure 4.20: RoR components responsible for the visualization of an ECG trace

The ecgs controller is responsible for retrieving the ECG data from the model and passing the data to the view component. For this the controller calls the method fetch recorded values() of the ecg model by providing the patients user ID and the trace ID previously received by an HTTP request. This request comes from the preceding view, which list all ECG traces available for a patient. The fetch recorded values() method uses the trace ID and user ID to retrieve all relevant records from the records table. For each retrieved record the values of lead 1, lead 2 and lead 3 are then retrieved from the ecg table, using the record ID value. The lead 1, lead 2, lead 3 values of the ecgs table and the record time interval values of the records table are then stored in individual arrays. For example the array temp lead 1 contains the lead 1 values of all relevant records. The created arrays are then put into another array called result which is returned to the records controller. Before storing the values of lead 1, lead 2 and lead 3 in corresponding arrays, the values are converted into millivolt (mV). This is done because the original values, retrieved from the database, represent binary values. The same is done for the record time interval values. These values are converted from binary milliseconds to seconds. The records controller which receives the result array, extracts the individual arrays holding the values for lead 1, lead 2, lead 3 and record time interval. These arrays are then passed to the corresponding view le (show.html.erb ). In the show.html.erb le the arrays are then converted to JavaScript arrays and inserted in the JavaScript code, responsible to display the ECG signal.



Chapter 5 Future Work

The mobile healthcare system described in the last two chapters can be extended in dierent ways to support additional functionalities. This chapter aims to present some future work that could be done for the mobile healthcare system. Three elds have been identied and could be the subject of further development: Processing and analysis of ECG data. Continously monitoring of ECG data in real time. Recording of additional biomedical data and environmental data. Subsequently these three elds will be described briey. After that some more ne grained enhancements concerning the mobile and server application will be presented.

Processing and analysis of ECG data The server could be extended to include an analyzing module for the recorded ECG data. This could consist of recognizing the recurrent wave sequence of P-, QRS- and Twave associated with each heart beat [47]. Especially the recognition of the RR interval and the QRS complex reveal crucial heart condition of a monitored patient [46]. Many dierent methods have been developed the past thirty years for detecting and classifying these features of an ECG signal [57]. Based on the categorization of the recognized features an automated cardiac desease diagnosis is possible, supporting the doctors in the interpretation fo the ECG signal. Furthermore the automatic detection of abnormalities could be used to notify the patient and doctors if a severe health condition occurs. The analyzing module could also include the extraction of information not readily available from the signal throught visual assessment [58]. For example the RR-interval could be used to calculate the heart rate of a patient [35]. 57



Continously monitoring of ECG data in real time The whole system could be improved to allow a continously monitoring of ECG data. That means the acquired data is send continuously from the sensor over the Android mobile phone to the server. At the present time the ECG data is recorded only periodically. Therefore the doctor looking at the ECG signal does not see the most recent ECG of the patient. As the condition of the heart can rapidly change, this will be an important extension to the described mobile healthcare system.

Support of further biomedical and environmental data The presented system could be improved to support the recording of futher biomedical data of a patient. As mentioned in section 2.3 the Shimmer platform provides several sensing capabilities like EMG, Gyroboard and so on. Regarding the communication capabilities of the Shimmer sensor it could be even possible to form a body area network of these sensors, each sensor recording specic biomedical data. The dierent recorded biomedical data could then be combined in the analysis of the patients health. Beside recording biomedical data using a sensor, the mobile phone could be used to record the location of the patient using GPS. This allows a wide range of new possibilities. For example the recorded location data could be used to retrieve information about the environment of the patients location. This could include current temperature and pollution extracted from a weather database. Further the pace at which the patient moved can be related to the recorded ECG data and the thereby derived heart rate.

Extending the mobile application and server application The server application could be extendend to provide further web services. Currently the mobile application only communicates with the web application to authenticate and send medical data to the server. Both, the server application and the mobile application could be extended to provide further functionalities for the user on the mobile phone. The subsequent list describes some functionalities that could be implemented. Allow the user to register an account on the web application from the mobile phone. Allow the user to see its ECG trace on the mobile phone. Allow the user to see, edit and update its personal data stored on the web server. Moreover the mobile application could be extended to provide a remote Bluetooth service. This means that other applications can use the Bluetooth service to connect to a Shimmer sensor and record biomedical data. At present time the Bluetooth service component is implemented as a local Android service. Therefore the Bluetooth service can only be used whithin the application. But the current implementation of the Bluetooth service can easily be extended to a remote service. To do this, an interface has to be implemented to

59 allow other applications to communicate with the Bluetooth service. This is done by using the Android Interface Denition Language (AIDL). This interface denition language is used to generate code that enables two processes on a Android mobile device to talk using interprocess communication (IPC) [12]. By allowing other applications to use the Bluetooth service, a platform of dierent applications may be thinkable. Each application designated to full a specic task.



Chapter 6 Summary and Conclusions

With the emergence of sophisticated wearable sensors and the advances in mobile communication , new opportunities open up for developing mobile healthcare systems which monitor biomedical signals from patients. Especially the continuous, or even sporadic recording of ECG signals, will improve the diagnosis and treatment of cardiovascular deseases by allowing a more realistic view on the patients health condition. Driven by these opportunities, sophisticated mobile healtcare systems will certainly arise in the near future, supporting and enhancing todays provided healthcare services. The goal of this thesis was to implement and design a prototype mobile healthcare system consisting of three parts: a Shimmer sensor that records ECG data from a patient in real-time, an Android mobile phone that forwards the received data from the sensor to a central server and nally a server responsible to store and display the recorded ECG data. Thereby, the system shall allow basic medical assessment of patients by their doctors. Two main requirements were dened for the system. First, the mobile healthcare application should allow the seamless transmission of the recorded data from the sensor to the server. Secondly, the system has to be designed in a way to be exible enough in order to support various types of biomedical and environmental data. At the end, a prototype mobile healthcare system was provided that features the main requirements dened. The system developed has the ability to periodically record the ECG of a patient and send it over an Android mobile phone to a central server. The patient and his doctors are then able to see the recorded ECG signal by accessing the web application. Further doctors can write a diagnosis in form of a comment under the ECG displayed, which allows basic medical assement of patients. For the implementation of the web application the Ruby on Rails framework was chosen. The main reason for choosing Ruby on Rails was, that it allows the fast development of a web application by putting convention over conguration and provides a straightforward structure for the web application. The overall system was designed in such a way that it can be extended regarding the support of other types of biomedical and environmental data. With this extensibility to various types of biomedical data, the presented prototype mobile healthcare system provides a solid base for further extensions or the development of a new system. 61



[1] Electrocardiography - Wikipedia: the free encyclopedia, wiki/Electrocardiography, 12th Oct. 2010. [2] Anwar Vahed: 3-Lead Wireless ECG, .php?page=3-Lead+Wireless+ECG, 15th Nov. 2005. [3] M. C. Mancini: Heart Anatomy,, last visited 7th Oct. 2008. [4] Open Handset Alliance,, last visited 21th Oct. 2010. [5] Alliance Overview - Open Handset Alliance, oha overview.html, last visited 21. Oct. 2010. [6] Android Overview - Open Handset Alliance, android overview.html, last visited 22th Oct. 2010. [7] What is Android? - Android Developers, what-is-android.html, last visited 21th Oct. 2010. [8] Data Storage - Android Developers, data/data-storage.html#db, last visited 21th Oct. 2010. [9] Android Fundamentals - Android Developers, /topics/fundamentals.html, last visited 21th Oct. 2010. [10] Bluetooth - Android Developers, /wireless/bluetooth.html, last visited 10th Oct. 2010. [11] User Interface - Android Developers, /ui/index.html, last visited 10th Oct. 2010. [12] Designing a Remote Interface - Android Developers, /guide/developing/tools/aidl.html, last visited 15th Oct. 2010. [13] E. Burnette: Hello Android - Introducing Googles Mobile Development Platform, The Pragmatic Bookshelf, 2008. [14] R. Meier: Professional Android 2 Application Development, Wiley Publishing Inc, 2010. 63



[15] S. Hashimi, S. Komatineni, D. MacLean: Pro Android 2, Apress, 2010. [16] Ruby on Rails,, last visited 10th Oct. 2010. [17] R. T. Fielding: Architectural Styles and the Design of Network-based Software Architectures, elding/pubs/dissertation/top.htm, last visited 10th Oct. 2010. [18] Ruby Programming Language,, last visited 10th Oct. 2010. [19] Ruby on Rails: Getting Started with Rails, started.html, last visited 22th Oct. 2010. [20] J. Williams: Rails Solutions: Ruby on Rails Made Easy, friendsof, 2007. [21] L. Richardson, S. Ruby: RESTful Web Services, OReilly Media, 2007. [22] Shimmer - Wireless Sensor Platform for Wearable Applications, http://www., last visited 23th Oct. 2010. [23] Wireless Sensor Technology (WSN/BSN), Pervasive / Ubiquitous Computing - Shimmer Platform,, last visited 23th Oct. 2010. [24] Wireless Sensor - Shimmer Expansion Modules, r-d/platform-features, last visited 23th Oct. 2010. [25] Wearable Wireless Sensor Platform - About Shimmer Research, http://www., last visited 23th Oct. 2010. [26] Shimmer Platform - Key Features,, last visited 20th Nov. 2010. [27] MSP430 16-bit Ultra-Low Power (MCU), Low Power Mixed Signal Processors, familyId=342, last visited 20th Oct. 2010. [28] TinyOS webpage,, last visited 20th Oct. 2010. [29] nesC: A programming Language for Deeply Networked Systems, http://nescc., last visited 21th Oct. 2010. [30] Y. Hao, R. Foster: Wireless body sensor networks for health-monitoring applications, Physiological measurement, Vol. 29, pp. 27-56, 2008. [31] A.Burns, B. R. Greene et al: SHIMMER - A Wireless Sensor Platform for Noninvasive Biomedical Research, IEEE Sensors Journal, Vol. 10, No.9, pp. 1527-1534, 2009. [32] M. J. McGrath, T. J. Dishongh: A Common Personal Health Research Platform Shimmer and BioMobius, Intel Technology Journal, Vol. 13, Issue 3, pp. 122-147, 2009.



[33] M. McGrath, T. J. Dishongh: SHIMMER and BioMOBIUS: A Health Research Platform,;jsessionid=CW1P52 YTUDTMVQE1GHPSKHWATMY32JVN, last visited 13th Oct. 2010. [34] Respository - tinyos-1.x, /tinyos/tinyos-1.x/, last visited 23th Oct. 2010. [35] An ECG Primer,, last visited 13th Oct. 2010. [36] J. Lee: ECG Monitoring in Theatre, u1105 01.htm, last visited 5th Oct. 2010. [37] The ECG Waveform, EKGQTinterval.htm, last visited 25th Oct. 2010. [38] Home | TRIL,, last visited 27th Oct. 2010. [39] BioMobious ECG application for Shimmer, /tinyos/tinyos-1.x/contrib/handhelds/apps/BioMOBIUS/ECG/, last visited 27th Oct. 2010. [40] TRIL | BioMobious, /biomobius.html, last visited 27th Oct. 2010. [41] SQLite Home Page,, last visited 5th Oct. 2010. [42] MySQL: The worlds most popular open source database, last visited 9th Oct. 2010. [43] rails ssl requirement at master - GitHub, requirement, last visited 29th Oct. 2010. [44] binarylogics authlogic at master - GitHub, #readme, last visited 29th Oct. 2010. [45] stns declarative authorization at master - GitHub, /declarative authorization, last visited 29th Oct. 2010. [46] F.Su, Q. Fang, I. Cosic: ECG R-R Peak Detection on Mobile Phones, Proceedings of the 29th Annual International Conference of the IEEE EMBS, pp. 3697-3700, 2007. [47] Review of Data analysis methods for Denoising and Characterizing ECG,, last visited 14th Oct. 2010. [48] Raphael Java Script Libray,, last visited 30th Oct. 2010. [49] W3C Scalable Vector Graphics (SVG) 1.1 Specication, TR/2003/REC-SVG11-20030114/, last visited 14th Oct. 2010. [50] H. Kew, D. Jeong, Wearable Patch-type ECG using Ubiquitous Wireless Sensor Network for Healthcare Monitoring Application, ICIS, 2009.



[51] P. F. Binkley, W. Frontera, D.G. Standaert, J.Stein, Predicting the Potential of Wearable Technology, IEEE engineering in medicine and biology magazine, Vol. 22, pp. 23-27, 2003. [52] The electrocardiogram - looking at the heart of electricity, educational/medicine/ecg/ecg-readmore.html, last visited 30th Oct. 2010. [53] J. Penders, J. Molengraft, L. Brown et al.: Potential and challenges of Body Area Networks for personal health, 31st Annual International Conference of the IEEE EMBS, pp. 6569-6572, 2009. [54] B. Gyselinckx, Ph. Mattelaer, R. Borzi: Human++: emerging technology for Body Area Networks, in Brave New Interfaces. Individual, Social and Economic Impact of the Next Generation Interfaces, Crosstalks, 2007. [55] W. Chung, C. Yau, K. Shin, R. Myllyla: A Cell Phone Based Health Monitoring System with Self Analysis Processor using Wireless Sensor Network Technology, Proceedings of the 29th Annual International Conference of the IEEE EMBS, pp. 3705-3708, 2007. [56] C. R. Baker, K. Armijo, S. Belka et al.: Wireless Sensor Networks for Human Health Care, 21th International Conference on Advanced Information Networking and Application Workshops (AINAW), 2007. [57] P. Hamilton: Open Source ECG Analysis, Computers in Cardiology, Vol. 29, pp. 101-104, 2002. [58] L. S ornmo, P. Laguna: Electrocardiogram (ECG) Signal Processing, Wiley Encyclopedia of Biomedical Engineering, 2006.

AAA AIDL CoC CRC CRUD DOM DSL DRY ECG EMG GSR HTML HTTP HTTPS MVC MCU REST RoR SDK SSL SVG URL WLAN W3C XML Authentication, Authorization, and Accounting Android Interface Denition Language Convention over Conguration Cyclic Redundancy Check Create, Read, Update and Delete Document Object Model Domain Specic Language Dont Repeat Yourself Electrocardiography Electromyography Galvanik Skin Response Hypertext Markup Language Hypertext Transfer Protocol Hypertext Transfer Protocol Secure Model View Controller Microcontroller Unit Representational State Tranfer Ruby on Rails Software Development Kit Secure Socket Layer Scalable Vector Graphics Uniform Resource Locator Wireless Local Area Network World Wide Web Consortium Extensible Markup Language




List of Figures
2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 Typical ECG waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sectioned view of the heart . . . . . . . . . . . . . . . . . . . . . . . . . . . Electrical conduction system of the heart . . . . . . . . . . . . . . . . . . . Standard 3-Lead ECG based on Einthovens Triangle . . . . . . . . . . . . Normal ECG waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6 6 8 9

Shimmer Sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Overview of Shimmers technical specications . . . . . . . . . . . . . . . . 11 Android System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 14 Ruby on Rails MVC Architecture . . . . . . . . . . . . . . . . . . . . . . . 18 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.10 Example of action show 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9

Mobile healthcare system context . . . . . . . . . . . . . . . . . . . . . . . 21 Use cases for the mobile application . . . . . . . . . . . . . . . . . . . . . . 23 Use cases for the web server application . . . . . . . . . . . . . . . . . . . . 24 System architecture of the mobile healthcare system . . . . . . . . . . . . . 26 System architecture of the mobile healthcare system . . . . . . . . . . . . . 27 Packet format for ECG and accelerometer data . . . . . . . . . . . . . . . 29 Android mobile database schema . . . . . . . . . . . . . . . . . . . . . . . 31 Architecture of the Ruby on Rails web application . . . . . . . . . . . . . . 33 Design of the communication between mobile application and web application 36

3.10 Database schema of the web application database . . . . . . . . . . . . . . 38 4.1 Mobile application user interface . . . . . . . . . . . . . . . . . . . . . . . . 39 69

70 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9

LIST OF FIGURES Composition of an activity . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 The activity MainView and its decomposition in view components . . . . . 41 Implementation of an section in main.xml . . . . . . . . . . . . . . . . . . 41

Sequence diagram of the authentication process . . . . . . . . . . . . . . . 42 Class: . . . . . . . . . . . . . . . . . . . . . . . . . 43 Example of an XML le received from the server . . . . . . . . . . . . . . . 44 User Interface of the BluetoothView activity . . . . . . . . . . . . . . . . . 45 Overview of the dynamic behavior of BluetoothView . . . . . . . . . . . . . 46

4.10 Package: bluetooth service . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.11 Periodical recording intervals . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.12 Process initiated by receiving ECG data . . . . . . . . . . . . . . . . . . . 48 4.13 Package: record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.14 Package: parser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.15 Class diagram of the record handler process component . . . . . . . . . . . 50 4.16 Package: database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4.17 Package: network service . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.18 Records controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.19 ECG signal of lead 1, lead 2 and lead 3 displayed by the web application . 54 4.20 RoR components responsible for the visualization of an ECG trace . . . . . 55

List of Tables
2.1 2.2 2.3 2.4 3.1 3.2 3.3 3.4 3.5 3.6 3.7 Heart chambers viewed by the 3-lead ECG . . . . . . . . . . . . . . . . . . Segments and intervals of an ECG wave . . . . . . . . . . . . . . . . . . . 8 9

Overview of Shimmer extension daughterboards . . . . . . . . . . . . . . . 11 Standard routing in Ruby on Rails . . . . . . . . . . . . . . . . . . . . . . 19 Overall system requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Requirements for the sensor component . . . . . . . . . . . . . . . . . . . . 22 Requirements for the mobile component . . . . . . . . . . . . . . . . . . . 24 Requirements for the web server application . . . . . . . . . . . . . . . . . 25 Package structure of the mobile phone application . . . . . . . . . . . . . . 29 Overwiew of the controllers developed for the web application . . . . . . . 34 Overview of plugins used for the web application . . . . . . . . . . . . . . . 35




Appendix A Installation Guidelines

A.1 Mobile Application

The Android application has to be installed using Eclipse. Subsequently the installation steps are described: 1. Import the Android project folder MobileSensingHealth into Eclipse. Copy the MobileSensingHealth folder from the CD to your desktop. Start Eclipse. Go to: File > New > Android Project. Choose: Create Project from existing source and provide the path to the MobileSensingHealth folder. Click Next and an Android project is created in Eclipse. 2. Start the application on a mobile device. Connect the Android mobile phone to your computer. On the mobile phone turn on debugging mode: Settings > Applicatons > Development > USB debugging. Right click on the MobileSensingHealth folder in the Package Explorer of Eclipse and choose: Run As > Android Application. Eclipse should now recognize the phone and the application is started.





Server Application

This installation guideline assumes that the Apache server is already installed and SSL is congured. Further it is assumed that MySQL is installed. 1. Redirect incoming requests from the Apache server to the Mogrel server. Use the provided httpd.txt le on the CD as an guideline. 2. Start the Apache server. Open a terminal and type: httpd -k start. 3. Copy the mobilesensinghealth folder, provided on the CD, to your desktop. 4. Congure the MySQL database. Open the database.yml le located in: mobilesensinghealth/cong/. Change the username and password in the development section. 5. Start the Mogrel server Open Terminal and go to the mobilesensinghealth folder. Then type the command: script/server. 6. Open a web browser and go to: http://localhost.

Appendix B Contents of the CD

The CD contains the following three folders: Thesis: contains the latex source code of the bachelor thesis and the abstract written in english and german. thesis.pdf abstract.pdf zfassung.pdf Mobile: contains the Android project folder. MobileSensingHealth Server: contains all les specic to the server development. httpd.txt: example of the conguration le used for the Apache server mobilesensinghealth: Folder containing the web application source code