Service Platform for Medical Training and Tourism

Successful submission to WISES workshop

Since February 2012 the University for Applied Science Constance offers a project for a service platform targeted e-bike tourism in the area of the Lake Constance. The goal of this project was to improve mobility for older tourists and beyond that increase physical activities of its users. The service platform should provide functionalities like routes management, tracking, weather forecasts and an emergency service. The whole project is a corporation of different departments of the university to achieve a better result combining different knowledge and professions. Responsible leaders are Prof. Dr. T. Thimm member of the department for Management and Social Sciences and focused on tourism and Prof. Dr. rer. nat. Ralf E.D. Seepold member of the department for Computer Science focused on the area of ubiquitous & mobile computing.

Prof. Dr. T. Thimm and her group of students act as domain professions researching existing platforms, collaborate with industry and traders in the tourism area and dealing with different questions what potential users expect of this software and how it can be deployed in an economic view. Prof. Dr. rer. nat. Ralf E.D. Seepold and his ubiquitous laboratory assume the technical part of the project, providing knowledge and concrete implementations. During the research period of the project the domain professions and the technical division work closely together, closing information gapes and exchanging ideas. An important part of this department interchange process was meetings in which different topics were discussed like user’s acceptance of such a service platform, feedback of industry partners, or technical limits and possibilities. This approach led to a first draw of technical service platform architecture and an improvement of the basic idea not only focusing on the target group of tourism but widen the idea to other areas especially the area of mobile health care.

With the change of the target audience, also the technical requirements had changed. The new idea of the service platform is to interchange vital data (e.g. heart rate) of patients in rehabilitation during physical exercises. Collected data and corresponding information will be supervised by medical professional with the goal for efficiency medical care and thus reduction of costs. The platform provides a service architecture supporting the integration of sensors, which provides the possibility to automatically monitor retrieved vital data and identify anomalies (e.g. heart rate exceeds critical threshold) and react accordingly as well as compare this data with a given personal health plan (roadmap) . Medical professionals and patients can access the data and use it collectively with the system to plan further activities, which provides the best rehabilitation process.

The architecture of the system is designed as a client-server architecture based on three parts:

  • Client

The client consists of a smartphone with the mobile application, which is connected to the service platform via a common communication interface. The application provides several services for collecting and measuring collected information of external sensors.

  • Sensors

An important part of the project are sensors. In this case there are two types of sensors internal and external. Internal sensors are embedded into the smart phone by default this can be GPS, compass or accelerometer. External sensors will be connected via an communication interface (e.g. Bluetooth) with the smartphone. For this project important information is the heart rate provided by an external heart rate monitor sensor. All this sensors gather user depended information and forward it to the client.

  • Server / Service platform

The server is a stationary node in the internet. It hosts the service platform and follows the method of “Software as a Service” (SaaS). Every service is clearly defined and separated from each other. The service platform collects the gathered information from the clients and use different services for analyze the data and visualize it on a web interface as the top layer. With the service oriented architecture it is easy to replace or add services for new functionalities.

 

 system arch

Figure 1: System architecture

Figure 1 demonstrates the basic system architecture. The part above the dotted line shows the service platform with the internal service oriented architecture and also the communication with the clients, shown beyond the dotted line.  Furthermore the graphic demonstrates the collection of internal & external sensors.

A first prototype has been implemented partly supporting the general system architecture. In order to provide quick feasibility checking, an existing proprietary platform was selected that supports real-time tracking provided by Bernot IT. The platform allows the interchange of data by a RESTful interface. JSON was chosen as the format of interchange messages containing corresponding information because in comparison with XML it has a less resource intensive behavior for the parsing of messages and furthermore is much easier reading for human being. The client application was built with the mobile framework Phonegap, which allows developing mobile applications with modern web technologies like HTML5, CSS 3.0 and JavaScript, in this case JQuery. An important benefit of phonegap is the possibility to develop an application once and at the same time deploy it on several different mobile operating systems like iOS, Android, Windows Phone etc. For the user interface JQuery mobile was chosen. It provides typical user interface elements optimized for mobile devices. Basic functionality of the client application is the tracking of positions with basic geometric algorithms, to measure distance between geo position as well as their bearing. Collected geo positions and their measured information will be uploaded to the service platform, which can be downloaded to the clients. A simple navigation system uses downloaded route information to show a compass pointing from the current geo position to the next geo position.  During the navigation the current distance to the target will be calculated permanently.

routing

Figure 2: Routing tags visualized

Figure 2 demonstrate a Google Maps map as part of the service platform web interface. On the map a tracked route will be displayed, which can be downloaded via a client. The red line shows the concrete tracked route. For comparison a reference calculated by the Google Maps Direction Service will be displayed as a blue line. A disadvantage of the Google Maps Direction Service is the limited number of geo position, which can be used for a calculation. This could lead to a vary visualization of routes. Another functionality is to plan routes online with the web interface, so the user has the possibility to create an own route online, download it on its smartphone and use the built-in navigation to follow the route. The basic and modern idea, the design of the system architecture and the first prototype led to a poster creation, which was submitted to the Wises workshop for Intelligent Solutions in Embedded Systems this year in Klagenfurt (Austria). Additionally to the poster the project was presented by Prof. Dr. rer. nat. Ralf E.D. Seepold personally. For further information visit the WISES homepage or download the poster about the service platform for medical training.


News Archive