ist programme - mobihealth.org fileattached as annex to this report. ... the major components of the...

IST-36006 MobiHealth Deliverable 2.6

1

IST Programme

Project Number: IST-2001-36006 Acronym: MobiHealth

A project funded by the European Community under the “Information Society Technologies” Programme (1998-2002)

Final, exploitation ready MobiHealth BAN (D2.6)

(Demonstrator report)

Editor: Dimitri Konstantas Authors: Richard Bults, Katarzyna Wac, Aart van Halteren Preparation Date: April 29, 2004 Version: 1.0 Contract Start Date: May 01, 2002 Duration: 22 months, (February 29, 2004) Project co-ordinator: Rainer Herzog, Ericsson GmbH


2

Executive Summary This document presents and overview of the system, hardware and software, developed in the MobiHealth project. A high level description of the systems is presented, as well as some technical details on the architecture of the system. One of the user’s manuals is attached as annex to this report.

The MobiHealth System Components The major components of the MobiHealth system are the Body Area Network, the Back-end system and the end-user system. The Body Area Network is a collection software programs and hardware devices. The communication is between the devices done by Bluetooth. The Back-end system is the software system that registers the incoming signals and makes them available for further processing. The end-user system comprises the applications running on the iPAQ, for the patient/medical personnel, and the viewer application (portiLab) running on the medical personnel PC, allowing the visualization of the vital signals.

Figure 1 MobiHealth UMTS Trauma BAN (excl. sensors)

Figure 2 MobiHealth GPRS Pregnancy BAN (incl. sensors)


3

Figure 3 MobiHealth Trauma BAN demonstration

Figure 4 MobiHealth Pregnancy BAN demonstration

Figure 5 MBU display - Respiration

Figure 6 MBU display - Plethysmogram

Figure 7 MBU display - Saturation


4

Figure 8 MobiHealth End-User Application (PortiLab2)

Services Layered Service Concept The MobiHealth system is designed to deliver an m-health service to its end-users (e.g. healthcare providers, healthcare practitioners, patients). The MobiHealth system consists of many interacting components that are distributed logically (one physical entity) or physically (many physical entities). The interacting groups of components of the MobiHealth system may be joined into sub-systems based on common functionality. These sub-systems interact with other sub-systems and also provide services to these sub-systems. The ability of sub-systems to interact is known as inter-operability. Since inter-operability plays a major role in distributed systems, the design of these interactions requires a great deal of attention, like a system in itself. This forms the basis for the design of the interaction system in a distributed system. Examples of interaction systems are: interfaces, protocols, services, inter process communication definition, inter connection definition, etc. The MBU and BEsys are two easy to identify sub-systems of the MobiHealth distributed system. The MBU acts as a data server system responsible for delivering (BAN) data – on request by the BEsys - to the BEsys client system. The end-to-end communication


5

path including the intermediate systems (Internet gateway, Enterprise router) is considered the third sub-system and denotes the interaction system that provides the data transport service for MobiHealth system. The MobiHealth services can be based on two end-to-end data transport service categories: unreliable transport service or reliable transport service. In other words: the server (MBU) and the client (BEsys) have two options to interact with the transport service provider. It’s mandatory to use the same transport service for both the server and the client. The interaction point for unreliable transport service and reliable transport service is referred to as U_SAP and R_SAP (figure 9). The server and client are decomposed in a protocol entity (PE) and application. The protocol entity interacts with the transport service provider and the application. The protocol entities main functions are: adaptation and presentation of application data to a suitable format for the transport service provider and vice versa, and establishment and termination of communication sessions with the transport service provider.

Figure 9 MobiHealth service decomposition Transport system The MobiHealth transport system is considered as a whole and presented as an abstract design model to master the complexity of the system. The transport service is not delivered by one transport system belonging to one organizational entity acting as a service provider. In general a MobiHealth transport system consists of three transport systems belonging to at least three organizations. It’s therefore necessary to identify these systems through decomposition of the transport system. If each sub-system is responsible for a section of the ‘end-to-end’ communication path used between MobiHealth system components, than the ‘end-to-end’ communication path can be decomposed according to Figure 10..


6

Figure 10 MobiHealth end-to-end communication path. Sensor system (vital sign) data is transmitted over a short range wireless link (e.g. Bluetooth) to the MBU (Mobile Base Unit = central node of the BAN). The MBU processes the data and relays the data to a Mobile Operator Network. The data is further transmitted by the operator to the Internet and finally arrives at the BEsys (MobiHealth security, control, management and data storage sub-system) in an enterprise network (e.g. healthcare provider LAN). The end-user of the MobiHealth service connects from a host within the enterprise network to the BEsys to control the behaviour of the BAN and obtain the measured (vital sign) data. BAN Interconnect Protocol The MobiHealth system delivers to its users an ambulatory health monitoring service. In order to deliver this service, some suitable application, and consequently the application protocol, needs to be executed in the MobiHealth system. While referring to the figure 10, there is a client/server application running in the MobiHealth system and there are two application protocol entities, namely: Server PE (which is MBU related) and client PE (BESys related). While analysing the behaviour of the MobiHealth system on the MobiHealth application level, there are three basic operating phases of the system delineated: • Setup of the connection between the client and server (server initializes the

connection), • Data transfer between the server to the client (server initializes the data transfer) • Connection termination phase While considering the execution of the MobiHealth services, not only the MobiHealth application is of interest, but also the protocols on top of which the MobiHealth application is running on. Particularly, the MobiHealth application protocol is running on top of the HTTP (standard) application protocol, and due to that, Client and Server PEs, can be decomposed into the two specific protocol sub-entities: MobiHealth PE and HTTP PE. Protocol entities identified in the HTTP protocol layer are: HTTP server PE and HTTP client PE. The assignment of roles is contrary to the one introduced on MobiHealth application layer. This is due to the fact that the MobiHealth server PE acts as a client on


7

the HTTP layer and, analogously, the MobiHealth client PE acts as the server on HTTP layer. This is illustrate in figure 11.

MobiHeApp

Figure 11 Decomposition of Protocol Entities in MobiHealth System

The communication between the HTTP Client PE and HTTP Server PE is based on three separate channels – registration channel, management and data channel. The complexity of communication between entities follows form the fact, that on the application layer, there could be multiple MobiHealth server (HTTP client) PEs attached simultaneously to a single MobiHealth client (HTTP server) PE, and moreover, for one MobiHealth server, there could be many simultaneous sources of service data (source of data is called a Sensor Set). Particularly, registration channel is a well-known channel for every MobiHealth server (MBU). Moreover for each server there is a separate management channel to the client (BEsys), and finally, for each Sensor Set attached to the server, there is a separate data channel to the MobiHealth client. MobiHealth system as viewed from the MobiHealth application level, under the assumption that there is a single MobiHealth server (MBU) entity with multiple Sensor Set entities, is presented on figure 12.

SensorSet

Figure 12 MobiHealth system functionality

Moreover, while analyzing the behaviour of MobiHealth system on the HTTP protocol level, there are three basic operating phases of the system delineated, and each of these phases is executed over the different communication channels:


8

• Setup of the connection between the HTTP client PE (MobiHealth server PE) and HTTP server PE (MobiHealth client PE) phase; the registration of the HTTP client PE to the HTTP server PE, which is executed over the registration channel,

• Connection management phase - transfer of management data done over the management channel

• Service related data transfer from the HTTP client PE to the HTTP server PE - executed over the data channel.


9

Annex I.

T-Mobile Mobile Future House MobiHealth demo

Manual March 9, 2004

ing. Richard Bults University of Twente

Phone: +31 (0)53 489 3743 Email: [email protected]


10

Demonstration setup:

Mouse

Firewall (SSH)

Mobi4

Finger Clip Sensor

Bluetooth

Internet

Internal

External

Laptop

Sensorviewer

Equipment: No Item Serial no.

1 ASUS L3800 Series Notebook PC wireless keyboard 2BNP004200

1 AC Adapter, ADP-90FB REV.F (19V DC 4.74Amp) U0W0242068155

1 ASUS USB optical mouse, M-UV55a LNA32619277

1 3Com Bluetooth Wireless PC Card version 2.0, 3CRWB6096, BT addr. 00:04:76:E1:48:C9 HRRPE148C9

1 TMSI Mobi4, 3e1as 0924030022

1 Nonin 8000K2 Finger Clip Pulse Oximeter Sensor 101308703

1 Nonin Xpod Model 3012 118502890

2 Duracell AA batteries

Note: Equipment represents a total value of EUR 2500. Please take action to insure the equipment.


11

Manual: I Setup MobiHealth demo system

1) unpack ASUS Notebook PC and peripherals box 2) plug in ASUS USB mouse (USB port on back of Notebook PC)

3) insert 3Com Bluetooth Wireless PC Card into the Notebook’s top (!)

PCMCIA slot

fig 1 – Notebook PCMCIA (top) slot

fig 2 – insert Bluetooth PC Card

4) put the antenna of the Bluetooth Wireless PC Card in operational position

fig 3 – press antenna holder to eject

fig 4 – put antenna in operational mode

5) connect the AC adapter to Notebook and 220V socket 6) open the batteries compartment of the TMSI Mobi4, insert 2 AA batteries and

close the compartment (“clicks”)


12

fig 5 – insert 2 AA batteries in Mobi4 7) connect Nonin 8000K2 Finger Clip Sensor to Nonin Xpod

fig 6 – Nonin Xpod

fig 7 – Nonin 8000K2 Finger Clip Sensor

fig 8 – connect Xpod to Finger Clip


13

8) carefully align the Nonin Xpod (metal) connector’s cam and insert it in the

TMSI Mobi4

fig 9 – Xpod connector, cam is inline with red dot

fig 10 – notch on top of Mobi4 connector

fig 11 – connect Xpod connector to Mobi4


14

II Start MobiHealth demo system

1) start the MobiHealth demo system by pressing the start button on notebook PC and wait until the “SuSE Linux 8.2 (mobihealth)” screen appears

2) login as “root”, password “mh4u”, “KDE 3.1” screen appears and wait for the

“MobiHealth” logo to appear on the screen

3) start the TMSI Mobi4 by pressing button on top for 1 second and wait for a green LED

4) click once with left mouse button on the “SensorViewer.sh” icon (top left of the

screen)

Note: If a communication problem arises between the Sensor Viewer application and the TMSI Mobi4 device a “Viewer” window (fig 12) appears on the screen. Click (left mouse button) on the “OK” button and check if the TMSI Mobi4 was switched on (green LED); if not, go to step 3, else stop the TMSI Mobi4 by pressing button on top for 1 second and wait for green LED to be switched off. Start again at step 3.

fig 12 – “Viewer” window with communication error message

5) select “SawTooth” tab in “Sensor Viewer” window; a running “sawtooth” shaped signal must appear in the window


15

fig 13 – “running” sawtooth signal 6) put the Nonin 8000K2 Finger Clip Sensor on the “pointing” finger (note: it takes

~15 seconds before the a proper reading can be displayed by the Sensor Viewer)

fig 14 – Finger Clip on finger


16

7) select “SaO2”, “Pleth” or “HeartRate” tab (top of Sensor Viewer window) to

show:

a. SaO2: Saturation O2 (Oxygen) = haemoglobin, the oxygen carrying substance found in blood, saturated with oxygen (fig 15).

b. Pleth: Plethysmogram = a tracing made by a plethysmograph (i.e. Nonin Pulse Oximeter Sensor), an instrument for determining and registering variations in the size of an organ or limb (e.g. finger of a hand) resulting from changes in the amount of blood present or passing through it (fig 16).

c. HeartRate: Heart Rate in beats per minute, derived from the plethysmogram (fig 17).

fig 15 – Saturation

fig 16 – Plethysmogram

fig 17 – Heart Rate


17

III Stop MobiHealth demo system

1) click (left mouse button) on the “X” (top left of window) to stop the Sensor Viewer application

2) stop the TMSI Mobi4 by pressing button on top for 1 second and wait for

green LED to be switched off

3) click (left mouse button) on the bottom left icon on the task bar to pop-up selection menu and select “Logout root”

fig 18 – pop-up menu to select “Logout root” 4) select “Turn off computer” in the “End Session for “root”” window and press

“OK”

fig 19 – “End Session for “root” window


18

IV Transport MobiHealth demo system

1) close ASUS Notebook PC and remove AC Adapter 2) carefully put the antenna of the Bluetooth Wireless PC Card in transport

position and push it inside the PC Card (fig 20) 3) push the ASUS Notebook PC’s top PCMCIA release button and remove the

Bluetooth Wireless PC Card

fig 20 – Bluetooth Wireless PC Card in transport position, push the PCMCIA release button

4) put the MobiHealth demo system and its components into the original packing material

5) return address:

University of Twente Drienerlolaan 5 7522 NB Enschede The Netherlands attn. Mr ing. Richard Bults Department EWI-APS

ist programme - mobihealth.org fileattached as annex to this report. ... the major components of the...

Documents