Using Vital Sensors in Mobile Healthcare Business ApplicationsChallenges, Examples, Lessons Learned

Johannes Schobel, Marc Schickler, Rudiger Pryss, Hans Nienhaus, and Manfred ReichertInstitute of Databases and Information Systems, University of Ulm, James-Franck-Ring, Ulm, Germany{johannes.schobel, marc.schickler, ruediger.pryss, hans.nienhaus, manfred.reichert}@uni-ulm.de

Keywords: Sensor Framework, Android, Smart Mobile Device, Healthcare, Vital Signs, Mobile Business Application.

Abstract: Today, sensors are increasingly used for data collection. In the medical domain, for example, vital signs (e.g.,pulse or oxygen saturation) of patients can be measured with sensors and used for further processing. In thispaper, different types of applications will be discussed whether sensors might be used in the context of theseapplications and their suitability for applying external sensors to them. Furthermore, a system architecturefor adding sensor technology to respective applications is presented. For this purpose, a real-world businessapplication scenario in the field of well-being and fitness is presented. In particular, we integrated two differentsensors in our fitness application. We report on the lessons learned from the implementation and use of thisapplication, e.g., in respect to connection and data structure. They mainly deal with problems relating tothe connection and communication between the smart mobile device and the external sensors, as well as theselection of the appropriate type of application. Finally, a robust sensor framework, arising from this fitnessapplication is presented. This framework provides basic features for connecting sensors. Particularly, in themedical domain, it is crucial to provide an easy to use toolset to relieve medical staff.

1 INTRODUCTION

Today, mobile business applications, running on bothsmartphones and tablet computers, become increas-ingly important for the medical domain. This rangesfrom schedule management applications to complexprocess-oriented, mobile patient management sys-tems (Pryss et al., 2010; Pryss et al., 2012). Sincethese applications have evolved from administrative(e.g., bed planning) to operational (e.g., measuringblood pressure) tasks, it is necessary to support med-ical staff in their daily routine. This can be supportedthrough the integration of external sensors, which arenot built in the smart mobile device, for monitoringvital signs.

Due to heterogeneity of available external sensors,it becomes necessary to classify these devices. Thiscan be done, for example, based on the type of vi-tal signs a sensor can monitor (e.g., pulse or oxygensaturation), or the type of connection (e.g., Bluetoothor USB) the sensor supports. In addition to the di-versity of mobile operating systems (e.g., Android oriOS), various development aspects emerge that mustbe addressed. This ranges from different types ofprovided sensor data to the quality of gathered data(e.g., real-time or bulk-load data). Furthermore, cop-

ing with connection problems (e.g., disconnectionsbetween the participating devices) during mobile datacollection is challenging.

To evaluate these specific aspects, we presentour implemented mobile fitness application “XFitX-treme” that communicates with external sensors.Based on insights of this application, we want to cre-ate a sensor framework, which allows for the provi-sion of a variety of different vital signs to athletes orpatients using mobile applications with sensors.

The remainder of this paper is structured as fol-lows: Section 2 discusses our application scenario. InSection 3, basic concepts for developing a mobile fit-ness application are introduced, and the designed sys-tem architecture is presented. Section 4 discusses thecurrent status of our fitness application “XFitXtreme”and presents particular issues emerging during the im-plementation. Section 5 discusses related work, whileSection 6 gives a summary and a brief outlook for fur-ther research questions.

2 APPLICATION SCENARIOS

To evaluate our approach of integrating sensors in mo-bile business applications, we present a proper real-

world scenario (cf. Section 2.1). For this purposewe consider the fitness domain, in which we want touse external sensors to support athletes in daily work-out sessions. In particular, we want to show differentways of developing such mobile business applicationsintegrating external sensors. These considerations arethe basis for the system architecture and sensor frame-work in the further course of this paper.

2.1 Running Example

To evaluate respective issues presented in Section 1,we implemented a realistic mobile business applica-tion. It provides the basis how to use sensors for mon-itoring vital signs within a mobile application.

We decided to develop a fitness application. Be-sides standard requirements, such as robustness andapplicability, we focus on flexible real-time data col-lection from external sensors. To give athletes moreoptions for collecting information about their vitalsigns, we wanted to support a variety of vital sensors.Specifically, in this application, we used two differentsensors measuring two vital signs (heart rate, and oxy-gen saturation). Furthermore, both the processing andthe visualization of gathered data shall be adequatelysupported by the application.

The “XFitXtreme” application is used to supportathletes on doing CrossFit. The goal of this typeof fitness workout is to practice on many differentmethods, such as strength, speed, agility, or stamina.Thus, a maximum fitness of the entire body shall beachieved. A standard training session of CrossFit usu-ally lasts 60 minutes. Consequently, recording dataof such a training results in a considerable amount ofdata. In addition, athletes should be in constant con-trol of their vital signs, to prevent any risk of injury.These requirements of the fitness domain serve as aproper application scenario for the first usage of ex-ternal sensors within a mobile application.

2.2 Other Application Scenarios

Regarding sensor integration, we basically focus onmobile healthcare applications. We present three sce-narios from the medical domain, in which we revealedby interviewing physicians that they could be dramat-ically relieved in their daily routines. The healthcaredomain therefore has revealed different scenarios, inwhich patients could benefit from the use of these de-vices.

• Medical Ward Rounds in Hospitals: In theirdaily medical round, physicians have to deal withunscheduled patient examinations (Pryss et al.,2012), e.g., measure the blood pressure, or blood

sugar level. To collect this data more accurately,mobile healthcare applications integrating exter-nal sensors could be used. With the help ofsuch mobile applications, vital signs can be col-lected and automatically stored in the electronicpatient record. In addition, certain procedurescould be automatically started, depending on thecurrent patient’s vital signs. Consider for ex-ample, a doctor determines an increased bloodsugar level using his smart mobile device provid-ing a blood sugar sensor. The information willthen be documented and archived in the patient’selectronic record. The clinical decision supportsystem (Trowbridge and Weingarten, 2001) thencould suggest the procedure “schedule medicationfor lowering blood sugar level”.

• Rescue Service: Particularly in rescue servicesit is important to ensure fast, reliable, and real-time measurement of a patient’s vital signs. Inthis case, patients could benefit by using sensorsthat provide information about their health condi-tion. For example, rescue staff checks the oxygenlevel of a patient at accident site. With the help ofa smart mobile device and external sensors, it canbe easily checked, whether the patient is hyper-ventilating. If oxygen level is above 98%, coun-termeasures must be performed quickly to stabi-lize the patient.

Aside from the mentioned scenarios, the domain ofclinical psychology provides other interesting possi-bilities using sensor data in mobile applications.

• Psychological Questionnaires: In other researchprojects, we have already gathered experience re-garding the development of mobile business ap-plications for clinical psychology. This includesfor example the development of digital question-naires for collecting patient data. In this con-text demands emerged to integrate external sen-sors. For example, the patient’s vital signs couldbe monitored during data collection. Thus, an ex-ceptional patient behaviour will be indicated byhis vital signs. Consider the following example:A question “Do you take drugs?” is provided to apatient. If the patient answers with “No”, and theinterviewer observes that the patient’s pulse riseswhile giving the answer to this question, then shehas more indications to evaluate the quality of therespective answer. Therefore, pulse data associ-ated with this question is stored electronically andcan be used when evaluating the questionnaire.

The usage of external sensors, coupled with a mo-bile business application could improve the quality ofmedical healthcare procedures as presented above.

3 BASIC CONCEPTS &ARCHITECTURE

This Section will cover basic concepts, which haveto be carefully considered in the course of the de-velopment of mobile business applications aiming atthe integration of external sensors. In Section 3.1,we basically focus on the appropriate developmenttype of mobile applications (Web Application, HybridWeb, or Mixed Application, or Native Application).We consider this discussion as a fundamental aspectfor mobile application development. Section 3.2 de-scribes our implemented system architecture, whereasSection 4 discusses important implementation details.

3.1 Different Ways of DevelopingMobile Business Applications

Before beginning the development of a mobile busi-ness application, one has to consider the basic devel-opment type for the application. It determines thescope of provided features available in the applica-tion. In addition to this, based on the chosen typeof application development, aspects like program-ming language (e.g., Java or HTML5 and JavaScript)or architectural design patterns (e.g., Model-View-Controller) will be basically determined (Heitkotteret al., 2013). In the following, we define four differ-ent development types for mobile applications whichhave to be distinguished.

• Web Applications: This type of mobile businessapplication, e.g., jQuery Mobile Applications, isimplemented using HTML5, CSS, and JavaScript.Usually, the application code is rendered within amobile web browser. According to this, these ap-plications are independent of a platform and de-vice. Compared to native applications, this is alightweight approach. In contrast to their minimalimplementation effort, such applications providethe smallest set of functionality, because they relyon the feature set of a web browser.

• Hybrid Applications - Web: The applicationcode of this type of mobile business applications,e.g., Adobe PhoneGap Applications (Adobe Sys-tems Inc., 2013), consists of the same web tech-nologies as for real Web Applications. However,they run in a native application container (e.g.,iOS WebView), which, in turn, can provide ad-ditional functions.

• Hybrid Applications - Mixed: These type ofHybrid Applications, e.g., Appcelerator TitaniumApplications (Appcelerator Inc., 2013), provide acore of mobile development APIs which will be

Figure 1: Different types of mobile business applicationsaccording to (IBM Corporation, 2013).

normalized across platforms. These APIs can beused like known web technologies (cf. HybridApplications - Web). However, during the de-ployment of the application a mapping betweenelements of HTML5 and elements of the corre-sponding native platform must be automaticallyperformed.

• Native Applications: Native Applications, e.g.,Android Applications, represent the way of im-plementing mobile business applications using thestandard API. They are implemented using thenative programming language (e.g., Java for An-droid), and therefore require more special knowl-edge of device-specific development issues. They,in turn, offer the most possible functionalitythrough direct use of respective platform providedprogramming libraries and interfaces. In addition,native applications show the best performance andapplicability for users.

Figure 1 illustrates the previously mentioned de-velopment types of mobile applications pointing outthe differences related to application code.

Table 1 presents to advantages and disadvantagesof the different development types of applications.Considering the fact that we need access to devicefeatures like the Bluetooth communication stack, weonly can address the type of application that supportsthis specific feature. In addition, we want to achieve ahigh motivation using our fitness application. There-fore, a robust retrieval of sensor data and finally visu-alize the vital signs adequately will be crucial for theoverall user acceptance. Moreover, it should be possi-ble to integrate vendor-specific software, like customdrivers for sensors. All requirements have indicatedto us implementing the fitness application “XFitX-treme” as native application. We decided to developon the Android platform, because of its full access tothe Bluetooth communication stack.

3.2 Architecture

We have discussed different development types of ap-plications, and considered their advantages and disad-vantages. Based on this, we present our architectureapplied to “XFitXtreme”. Figure 2 therefore showsour architecture. In the further course of this Section,we will discuss the different conceptualized layers ofthe architecture in detail.

3.2.1 Android Application Framework

The Android Application Framework 1© encom-passes a set of APIs enabling the development of na-tive Android applications. Therefore it provides na-tive libraries that are accessible through those APIs.With these libraries, it is possible to access a database,call webservices, or communicate via Bluetooth. An-droid Applications (e.g., our “XFitXtreme” applica-tion) directly interact with this application frame-work, which manages basic functions of the smartmobile device, such as automatical resource manage-ment. Being a mobile business application developer,this basic toolset enables for building your own appli-cation.

3.2.2 XFitXtreme Application

The architecture of “XFitXtreme” 2© includes the fol-lowing major components of a mobile application:

• To ensure maximum flexibility and portability ofvarious components, the latter are strictly sepa-rated. This means that user-interface components

Figure 2: General architecture of XFitXtreme.

3©, such as widgets or activities, can be easily re-placed or adjusted without altering the specific ap-plication logic.

• The SQLite database 4© is a default feature ofAndroid and is used to store user data (e.g.,such as training information), application settings(e.g., such as language settings), and, for exam-ple, recorded vital signs from external sensors.Thus, it is basically possible to evaluate and visu-alize them afterwards. Accessing a database hasbeen provided through an encapsulated manage-ment component. The same applies to the localfile system 5©, which contains images or videos.

• The “XFitXtreme Specific Components” 6© in-clude classes and interfaces for the various fea-tures necessary in the fitness domain (e.g., admin-istration of workout). Furthermore, visualizingsensor data is implemented by the usage of theGoogle Charts API (Google Inc, 2013). This al-lows for a comfortable creation of charts based ongathered data from external sensors.

• The most important component of our “XFitX-treme” Application is the sensor framework 7©(cf. Section 4.2.5). This framework enables usto integrate new sensors easily, without reimple-menting basic functions like the establishment ofa Bluetooth connection. Our mobile business ap-plication “XFitXtreme” currently uses the Blue-tooth component feature of the framework, sinceexternal sensors in the fitness domain are usuallyconnected wireless.

3.2.3 Sensors

This Section introduces sensors 8© used in this projectfor collecting vital signs of the CrossFit athlete. In ad-dition to general information, we will present techni-cal challenges of the device sensors. Currently, weintegrated two different sensors, namely the “PolarWearlink+ Heart Rate Monitor” (Polar Electro GmbH

Table 1: Advantages and disadvantages for the different development types of applications.

Feature Web App Hybrid App - Web Hybrid App - Mixed Native AppExecution within Web browser WebView within Native Environment Native Runtime

Native Shell within Native Shell EnvironmentProgramming Language Web only Web only Native and Web Native onlyCode Portability High High Medium NoneAccess Device Features None Low Medium HighGraphics and Animations Medium Medium High High3rd Party Libraries JavaScript JavaScript JavaScript and Native NativeUser Experience Low Low Medium HighPerformance Low Low Medium High

Figure 3: Sensors used in our mobile business application.

Deutschland, 2013), and the “MedChoice Oxime-ter MD300C318T” (MedChoice, 2013), which areshown in Figure 3.

The “Polar WearLink+ Heart Rate Monitor” isone of only two Bluetooth athletic heart rate monitorsavailable for Android smart mobile devices. The sen-sor itself is clipped to a soft textile belt and is wornaround the chest (i.e., directly below the chest mus-cles). As soon as the belt is put on correctly andpaired with a device, it starts sending data packagesvia Bluetooth (2,4GHz frequency band). For pairing,no handshake is required, making it easy and straight-forward to use this external sensor.

The “MedChoice Oximeter MD300C318T” notonly provides the heart rate, but also measures theoxygen saturation of the blood. It was designedfor medical use and therefore offers more informa-tion than the Polar belt. The sensor itself has anOLED display which visualizes the retrieved vitalsigns showing both plain values and correspondingdiagrams (e.g., a bar chart as amplitude of the pulse).Compared to the Polar belt, this sensor needs a com-plex pairing and synchronization protocol to send vi-tal signs, but offers two different modes (e.g., real-time mode and non-real-time mode). Due to the factthat we want to support the athlete during his trainingsession, we have focused on the real-time mode.

4 PROOF-OF-CONCEPT

In this Section, the developed mobile business ap-plication “XFitXtreme”1 is presented as a proof-of-concept implementation. Section 4.1 describes theimplementation of the business application, whileSection 4.2 presents the lessons learned of thisproject.

4.1 The XFitXtreme Application

“XFitXtreme” is an application designed to displaythe functionality offered by the developed sensorframework. The framework establishes and managesa Bluetooth connection to a sensor the training athleteis wearing. The sensor used here is a chest belt withan integrated heart rate monitor from the “Polar Wear-Link+”. Other sensors have also been paired (e.g.,“MedChoice MD300C318T”, see Figure 4). “XFitX-treme” has the task of recording and graphically eval-uating the vital parameter supplied by the framework.Simultaneously, it is a tool satisfying all needs of theathlete training CrossFit. The UI is held clean andsimple to ensure an adequate display of the necessarydata and guarantee a good usability. “XFitXtreme”offers useful features described in the following.

The most important feature is supplying the indi-vidual training plan of the day. This is done in two dif-ferent ways. If internet access is available, the work-out is parsed from CrossFit website (CrossFit, Inc.,2013) using the “Workout of the Day” (WOD) fea-ture. This website posts and updates the “WOD” on adaily basis, which is a large advantage making train-ing plan logic unnecessary. If no connection is avail-able, the “Classix” feature offers a database, listingmany workouts held locally. These workouts are dis-played in a list, offering the possibility to view the ex-ercises included in the workout before selection. Af-ter choosing or parsing a workout, the exercises build-

1video available under http://vimeo.com/60436751

Figure 4: Dialog to connect to various external sensors.

ing up the workout are displayed in a list. This listcan optionally be posted on Facebook. The exercises,if not familiar, can be searched on YouTube by sim-ply tapping on the element in the list. If all exercisesare familiar, the play button leads to the final activity.This activity displays the entire workout and shows allrelevant data, including the heart rate data offered bythe framework. The best time for the daily workoutis automatically loaded by a web service accessing anonline database. The sensor is connected automati-cally via Bluetooth and, after that, starts transmittingdata. The beginning of the workout is signalized bypressing the go button. The application takes the timethe athlete needs to complete the workout and startsrecording the heart rate data. Finishing the work-out uploads the taken time, and the daily ranking isdisplayed so the athlete can classify his performance.The monitored data is visualized in a graph to give theathlete a quick overview of his vital activities duringthe workout (cf. Figure 5).

In addition to these main features, “XFitXtreme”offers further features to support the athlete in histraining. The first is a timer, which combines a sim-ple stopclock with a lap option and an interval timer.The stopclock can take time and a random number oflaps, which are displayed in a list. The interval timeroffers the possibility to set up individual timers andsave these persistently. These timers are displayed byname in a list after selecting this feature. Each timercan be named, an arbitrary number of rounds can beset and finally a random number of intervals can beadded. Each interval is characterized by a name, atime, and a color. These attributes are displayed lateron while playing the timer, so the athlete knows whichinterval is currently running. Selecting a timer fromthe list plays the timer. Each interval added to thetimer is displayed in the order set before, counting

Figure 5: Visualization of vital signs during the workout.

down the set time, displaying the name and the colorset as background color. That way, the change ofinterval is not only signalized acoustically, but alsovisually by a change in the background color. Theend of the workout is signalized by an applause. Thetimers can be deleted if no longer used.

CrossFit is unfortunately not too popular. De-pending on the area, in which the athlete is training,it can be difficult to find other people sharing theirpassion for this sport. Therefore, “XFitXtreme” of-fers an IRC chat. The latter is an open chat, in whichall users share a forum. This increases the chance ofathletes being online simultaneously, establishing anonline community. It is possible to send messages pri-vately to other users as well. These messages are notvisible for the other users in the forum, and are dis-played in a different color. That way both users knowthese messages are private.

4.2 Lessons Learned

In this Section, we present aspects elicitated duringthe development of this mobile business applicationusing the two mentioned external sensors.

4.2.1 Basic Development Types for MobileApplications

The market research company Gartner predicted inearly February 2013, that by 2016, 50% of all mo-bile business applications are developed using hy-brid technologies (Gartner, Inc., 2013). We re-alized while designing and implementing “XFitX-treme”, that none of the current available hybrid ap-proaches (e.g., PhoneGap, Appcelerator) met the es-sential requirements for our application. The sameapplied to the implementation of pure web applica-

Table 2: Bluetooth support for different development typesof business applications.

Bluetooth SupportWeb App No SupportHybrid App - Web Limited SupportHybrid App - Mixed Limited SupportNative App Full Access

tions. We revealed unrestricted access to the Blue-tooth API and full support of the specified Bluetoothprofiles (e.g., SPP profile) as the most important argu-ments for developing our native mobile business ap-plication “XFitXtreme”. These features are not avail-able within a hybrid development framework, such asPhoneGap or Appcelerator. Without this capability,the integration of external and wireless sensors is notpossible.

Table 2 shows the Bluetooth support for the dif-ferent development types of applications defined inSection 3.1.

Furthermore, these hybrid development frame-works did not fulfill our requirements regarding per-formance of data processing, and a suitable as wellas interactive visualization (e.g., using animated dia-grams).

4.2.2 Establishing a Connection

One challenging issue we encountered while usingexternal sensors was the handling of different typesof connections, such as Bluetooth, USB, Infrared,or Wi-Fi. Depending on their characteristics, somevendor-specific communication mechanisms have tobe used. For example, the “Polar WearLink+ HeartRate Monitor” belt (Bluetooth connection) requires,after the successful pairing with the smartphone, nofurther synchronization or handshake techniques toobtain data. In contrast, the “MedChoice OximeterMD300C318T” (Bluetooth connection) sensor needsextended synchronization and a test sequence beforedata is available. Both sensors have in common thatdata is actively and periodically transmitted to thesmart mobile device (cf. Figure 6).

4.2.3 Structure of the Sensor Data Packages

In this Section, insights regarding to the structure ofthe data packages received by an external sensor areshown. The most challenging aspect has been thevendor-specific and proprietary exchange format. Noofficial documentation on the structure of data pack-ages was found for the “Polar WearLink+ Heart RateMonitor”. This information must be gathered through

Figure 6: Different communication mechanisms for the ex-ternal sensors.

Figure 7: Different structure of data of the implementedsensors.

internet research, or even worse, through reverse en-gineering of the data packages. In the case of “Med-Choice Oximeter MD300C318T” we received an ex-tensive documentation about the data packages aftersending a request to the producing company.

Figure 7 shows differences in the structure of thedata packages of our used sensors. They greatly dif-fer not only in length of transmitted data packages,but also in contained data. The “MedChoice Oxime-ter MD300C318T” provides more information aboutthe vital signs than the “Polar WearLink+ Heart RateMonitor”, which results in a more complex data pack-age structure (cf. Figure 7).

4.2.4 Connection Problems

We encountered a problem concerning connection is-sues. Both Bluetooth and Wi-Fi (B and G standard)transmit in the unlicensed ISM (Industrial, Scientificand Medical) frequency band of 2.4 GHz (Lansfordet al., 2001). This means, it may cause interferencewith a Wi-Fi network. This noise from other networkspossibly causes a connection loss between the smartmobile device and the external sensor, or a complete

Table 3: Bluetooth classes and approximate range

Bluetooth Class approx. RangeClass 1 approx. 100mClass 2 approx. 20mClass 3 approx. 10m

disconnection. In addition to this, Bluetooth has lim-ited range, depending on the Bluetooth class. Table 3shows the approximate range of different Bluetoothclasses (Bluetooth Developer Portal, 2013). Shortranges as a characteristic property of Bluetooth canbe critical. Especially in the medical domain whenthe physician moves too far from the patient and theconnection gets interrupted.

If the connection between the smart mobile de-vice and the external sensor gets disconnected, thequestion arises, how to suitably respond. One op-tion would be that the smart mobile device shouldtry to initiate a reconnect periodically. Dependingon the scenario, it is important to interact with theuser and inform him about the disconnection. Forour presented fitness application “XFitXtreme”, it isnot important, because no critical information mustbe exchanged. Nevertheless, in the medical domain,it could be very important to tell a physician that cur-rently there is no coupling between the devices (e.g.,smartphone and heart rate monitor), and hence noreal-time information about the vital signs is avail-able.

On the one hand, some external sensors have asmall internal memory, where data can be cached incase of a disconnection. Thus, it is possible to copewith a short time of disconnection and provide cacheddata in addition to the real-time values which havebeen gathered in the meantime. On the other hand,the smart mobile device has to deal with missing data.In some cases, already recorded data needs to be dis-carded, since the measurement is no longer valid.

In the context of a wireless connection betweenthe smart mobile device and external sensors, all thesequestions need to be considered.

4.2.5 Sensor Framework

Reflecting on the previously described lessons, wedeveloped a basic mobile sensor framework whichcan be easily integrated into existing Android appli-cations. It shall encapsulate already mentioned het-erogeneity of data structure of different sensors (cf.Section 4.2.3) as well as the communication betweenthe external sensor and the smart mobile device (cf.Section 4.2.2). In addition, connection problems (cf.Section 4.2.4) should be handled. Furthermore, the

Figure 8: Sensor framework architecture.

sensor framework should provide basic functionality,such as establishing a connection to a sensor, or re-ceiving data from a sensor. Finally, requirements,such as the extensibility, maintainability, or scalabil-ity have to be considered. Figure 8 shows the architec-ture of our sensor framework. The individual applica-tion layers are described in the following sections.

The “Android Application Framework” serves asthe basis for our mobile business application. Thisframework provides the fundamental functions andinterfaces (e.g., for the Bluetooth or USB connection).

Our described sensor framework consists mainlyof three layer, namely the Administration Layer,Communication Layer, and Specific Driver Layer.

The “Administration Layer” contains the “Frame-work Manager”, which is responsible for the basiccommunication with the framework. It provides ba-sic methods which an application developer needs touse external sensors in his mobile business applica-tions. This includes methods concerning the connec-tion (e.g., open or close a connection), receiving datafrom a sensor, or configuring a sensor using specialmessages. An application that implements the sensorframework communicates only with this frameworkmanager.

The second layer, namely the “CommunicationLayer”, provides all classes to manage the differenttypes of connections, like Bluetooth, WiFi, or USB.These classes rely on the Android Application Frame-work through the provided interfaces.

The third layer named as the “Specific DriverLayer”, includes classes for the individual sensors.These classes are derived directly from the associ-ated communication layer class, and contain informa-tion for setting up the connection. Consequently, onlymethods for configuring the sensor, or receiving thedata, will have to be implemented.

The “Wired & Unwired Sensors” layer repre-sents the external sensors connected to the mobile de-

vice. In our application scenario, these are the afore-mentioned discussed sensors “Polar WearLink+ HeartRate Monitor” and “MedChoice Oximeter”, whichprovide us with the gathering of vital signs.

5 RELATED WORK

In the following we will discuss related projects.For this purpose, we distinguish these projects intwo categories, namely “Consumer” and “Research”projects.

The most known example from the consumer do-main is the mobile application “runtastic” (runtasticGmbH, 2013), which is available on all major mobiledevice platforms. This application offers the abilityto integrate different pulse sensors to the mobile de-vice. The vital signs as well as the GPS position arerecorded in real-time. Finally, the gathered data canbe analyzed within the runtastic platform and sharedamong friends. Runtastic offers an easy to use ap-plication, with almost no installation or configurationeffort. Additionally, runtastic now offers its own hard-ware shop, in which 100% compatible GPS and pulsesensors can be bought.

Another well-known example of such an applica-tion is “Nike+” (Nike Inc., 2013). However, thereis a small sensor inserted into the shoe, which willthen track all movements (GPS position, distance, orstamina). This sensor is then connected to the smartmobile device to visualize the collected information.In addition, all “Polar WearLink+” sensors can beused and coupled with the smart mobile device in or-der to gather vital signs of the athlete.

Both consumer applications assume that the con-nection between the external sensors and mobile de-vice in the context of the fitness application is reliable.Unfortunately, we were not able to adopt their com-munication structure because of the proprietary phi-losophy. In addition, they offer hitherto only the useof pulse sensors.

Research projects like “Open Data Kit” (OpenData Kit, 2013) address a suitable mobile data col-lection. Open Data Kit aims at providing a self-containing framework for data collection. The in-tegration of external sensors in Android smart mo-bile devices are discussed in (Brunette et al., 2012)or (Chaudhri et al., 2012). Even though, we can notadopt results directly for our goal. The reason is thatwe can use “Open Data Kit Sensors” framework onlyinside the “Open Data Kit” project, which would be tocomplex. In addition to this, the applicability for ourfuture usage in the medical domain would be not suit-able. Instead, we are trying to create a sensor frame-

work, which can be used as a standalone application.Thus, we want to enable application developer to usethis framework in their own projects and applications.

6 SUMMARY & OUTLOOK

In this paper we presented a real-world mobile busi-ness application from the fitness domain. This ap-plication was implemented to be used with externalsensors for gathering vital signs of athletes in orderto support them in their frequent training sessions.To implement such a mobile application, we first hadto determine the appropriate development type of ap-plication (e.g., Web Application or Native Applica-tion). In case of the “XFitXtreme” application weimplemented a native application because of the lackof Bluetooth functionality for the other basic devel-opment types of mobile applications. Moreover, weaim at real-time processing and visualization of gath-ered vital signs and hence a challenging and realisticapplication was a must. Additionally, we presenteda system architecture for business applications thatshall be used with external sensors and explained ourlayered design. To strengthen our described archi-tecture, the fitness application “XFitXtreme” using itwas shown. However, we set the main focus on thelessons we have learned from this project. We there-fore discussed different aspects related to the connec-tion between the mobile device and the external sen-sor as well as different structures of data packagesretrieved by the external sensors. Our experiencesresulted in developing a sensor framework, which iscurrently used in a real-world fitness application. Theframework was discussed, and needed functions forthe CrossFit training were presented.

In the future, we plan to extend the sensor frame-work described in this paper. We plan a feature toadd more sensors, and support different types of con-nection standards as well, such as ANT, ANT+ (Dy-nastream Innovations Inc, 2013), or ZigBee (ZigBeeAlliance, 2013). Furthermore, we want to implementa mobile process engine to interact with the coupledexternal sensors using our described sensor frame-work. This would empower us to carry out the datacollection with sensors as a process. However, prob-lems, like flexibility, should be carefully considered(Reichert and Weber, 2012). Besides technical im-provements, we want to add more features to visualizegathered data from sensors. We therefore want to im-plement the Google Charts Tools (Google Inc, 2013)in our sensor framework to allow athletes to interac-tively browse through their different vital signs. An-other goal we pursue is to provide this sensor frame-

work on other mobile operating system, like ApplesiOS. This enables us for example to reveal insightsto the interplay between the iOS platform and exter-nal sensors. Finally, we focus more on scenarios ofthe medical domain using our framework to ease dailywork of medical staff.

REFERENCES

Adobe Systems Inc. (2013). PhoneGap.http://www.phonegap.com/. last visited:22. February 2013.

Appcelerator Inc. (2013). Titanium Mo-bile App Development Platform.http://www.appcelerator.com/platform/titanium-platform/. last visited: 22. February 2013.

Bluetooth Developer Portal (2013).Compare with other Technologies.http://developer.bluetooth.org/TechnologyOverview/Pages/Compare.aspx. last visited: 22.February 2013.

Brunette, W., Sodt, R., Chaudhri, R., Goel, M.,Falcone, M., Van Orden, J., and Borriello, G.(2012). Open data kit sensors: a sensor inte-gration framework for android at the application-level. In Proceedings of the 10th internationalconference on Mobile systems, applications, andservices, pages 351–364. ACM.

Chaudhri, R., Brunette, W., Goel, M., Sodt, R.,VanOrden, J., Falcone, M., and Borriello, G.(2012). Open data kit sensors: mobile data col-lection with wired and wireless sensors. In Pro-ceedings of the 2nd ACM Symposium on Com-puting for Development, page 9. ACM.

CrossFit, Inc. (2013). CrossFit - Forging Elite Fit-ness. http://www.crossfit.com/. last visited: 22.February 2013.

Dynastream Innovations Inc (2013). THIS ISANT - the Wireless Sensor Network Solution.http://www.thisisant.com/. last visited: 22.February 2013.

Gartner, Inc. (2013). Gartner Says by2016, More Than 50 Percent of Mo-bile Apps Deployed Will be Hybrid.http://www.gartner.com/newsroom/id/2324917.last visited: 22. February 2013.

Google Inc (2013). Google Chart Tools.https://developers.google.com/chart/. lastvisited: 22. February 2013.

Heitkotter, H., Hanschke, S., and Majchrzak, T. A.(2013). Evaluating cross-platform development

approaches for mobile applications. In Web In-formation Systems and Technologies, pages 120–138. Springer.

IBM Corporation (2013). IBM Work-light - Mobile application platform.http://www-01.ibm.com/software/mobile-solutions/worklight/. last visited: 22. February2013.

Lansford, J., Stephens, A., and Nevo, R. (2001). Wi-fi(802.11 b) and bluetooth: enabling coexistence.Network, IEEE, 15(5):20–27.

MedChoice (2013). The MedChoiceMD300C318T. http://www.pulsoximeter-gerate.com/products.asp. last visited: 22.February 2013.

Nike Inc. (2013). Nike+.http://nikeplus.nike.com/plus/. last visited:22. February 2013.

Open Data Kit (2013). Open Data Kit - mag-nifying human resources through technology.http://opendatakit.org/. last visited: 22. Febru-ary 2013.

Polar Electro GmbH Deutschland (2013). PolarWearLink+ Sensor Bluetooth. http://www.polar-deutschland.de/de/produkte/. last visited: 22.February 2013.

Pryss, R., Langer, D., Reichert, M., and Haller-bach, A. (2012). Mobile task management formedical ward rounds - the medo approach. In1st Int’l Workshop on Adaptive Case Manage-ment (ACM’12), BPM’12 Workshops, LNBIP.Springer.

Pryss, R., Tiedeken, J., Kreher, U., and Reichert, M.(2010). Towards flexible process support on mo-bile devices. In Proc. CAiSE’10 Forum - Infor-mation Systems Evolution, number 72 in LNBIP,pages 150–165. Springer.

Reichert, M. and Weber, B. (2012). Enabling Flex-ibility in Process-Aware Information Systems:Challenges, Methods, Technologies. Springer,Berlin-Heidelberg.

runtastic GmbH (2013). runtastic - makes sports fun-tastic. http://www.runtastic.com. last visited: 22.February 2013.

Trowbridge, R. and Weingarten, S. (2001). Clinicaldecision support systems. Making health caresafer: a critical analysis of patient safety prac-tices. Evidence Report/Technology Assessment,(43).

ZigBee Alliance (2013). ZigBee Alliance - Controlyour world. http://www.zigbee.org/. last visited:22. February 2013.