Srdjan Krco, Srdjan Kostic, Dejan Sakac, Zoran Lukic. Abstract - In this paper a mobile system designed for continuous health monitoring of individuals is ...
EUROCON 2005
Serbia & Montenegro, Belgrade, November 22-24, 2005
mSens Mobile
Health Monitoring System
Srdjan Krco, Srdjan Kostic, Dejan Sakac, Zoran Lukic In Section II, the overall system architecture of a personalized mobile health care system and its main benefits are given. Architecture and implementation details of an intelligent sensor control unit and a communication control unit are described in sections III and IV respectively. Section V describes implementation of the central repository subsystem with a corresponding web application. Section VI describes the subsystem interface. Section VII concludes the paper.
Abstract - In this paper a mobile system designed for continuous health monitoring of individuals is presented. The system is self configurable, supports multiple simultaneous measurements and can be easily adapted to suit specific circumstances and requirements of each patient. The architecture of the system is described. Experience gained during a prototype implementation is presented as well. A particular focus is given to a XML based communication framework the system is based on. XML gives a considerable flexibility required to describe a variety of sensor types and their parameters.
II. SYSTEM ARCHITECTURE
System architecture of the mSens mobile health monitoring system is presented in Figure 1.
Keywords - mobile health care, ad-hoc networks, wireless sensors I. INTRODUCTION
Long hospital waiting lists, shortage of hospital beds and the lack of qualified medical personnel combined with the requirement to reduce the cost of running a health care system are presenting common problems across the world today. In addition to this, the world population is steadily getting older and this has given rise to various chronic and age-related disabilities and diseases. The increase of elderly and chronic patients put a significant burden on both the health care system and adult caretakers who are looking after their elderly parents and relatives. These factors significantly impact the quality of provided health care services and are reducing the overall user satisfaction. Introduction of personalized mobile health care monitoring systems and solutions into the mainstream health care service presents a viable option that can help in alleviating problems described above. Personalized mobile telemedicine systems are designed for continuous monitoring of a customizable number and type of health parameters regardless of patients' locations. Monitoring is seemingly provided with a minimum amount of effort, disturbance and cost to all involved parties [1], [2], [3], [4]. In this paper, architecture of the mSens, a mobile telemedicine system, is presented and implementation details of a prototype are described. mSens architecture in combination with the XML based XMLSens protocol which is designed to support communication with various types of sensors and is able to transfer various data types in different formats, it comprises a flexible platform that can support a broad range of user requirements.
u
%9
N. .
400-0...
."
..NO
WMM .1i
Figure 1 mSens system architecture The following components comprise the system: one or more intelligent wireless sensors; a mobile patient's control unit; a mobile doctor's control unit; a central repository database; and an expert web application. Intelligent health-care sensors are attached to a patient body and are embedded into his/her everyday environment (chairs, tables, cups, doors, etc.). Sensors communicate wirelessly with a patient's mobile control unit in order to receive user commands and send measurements. The number and the type of sensors in a system can be changed in an ad-hoc manner, depending on the specific needs and requirements of each patient at a given time. Patients' mobile control units are used to temporarily store, display and forward gathered measurements to a central database where the data is permanently stored. These units use GPRS or 3G mobile networks to communicate with a central repository. Doctors use their mobile control units primarily to receive notifications in urgent situations and to quickly assess the health status of their patients on such occasions. In such situations doctors receive patient's data in realtime or with a very short delay. Also, they are able to remotely control settings of a patient's health sensors in order to modify and adapt their functionality to a given situation and the patient's health status. The central database component is a standard relational database that stores health data and other relevant
Srdjan Krco and Srdjan Kostic are with LM Ericsson Ireland (e-mail: srdjan.krcbericsson.com, srdjan.i.kosticgericsson.com) Dejan Sakac is with Insitute for cardiovascular deseases, University of Novi Sad (e-mail: dejsakacgeunet.yu).
Zoran Lukic is with the School of Technical Sciences, University of Novi Sad, Serbia & Montenegro (e-mail: lukiczguns.ns.ac.yu).
1-4244-0049-X/05/$20.00 (C2005 IEEE
.X
80
processor that contains a full Bluetooth protocol stack, supports serial port profile and provides an RS-232 interface for interaction with user's applications. The module is controlled using AT commands that makes this an easy to implement alternative. Sensing subsystem consists of one or more sensors that are connected via the A/D converter to the control subsystem. A particular care has to be taken of disturbances that can impact signals generated by sensors. In the initial prototype implementation, A/D converter was located on the same PCB as the micro controller and it caused disturbances to the observed ECG signal that could result in rasing false alarms for example. To avoid this problem, we implemented a "Faraday cage" around the converter. A three leads ECG module otherwise used in a Holter device was used as the sensing subsystem in the prototype. The output of the module is analog signal in -5V to +5V range.
information about all patients in the system permanently. It is accessible over a fixed or mobile Internet connection. The expert web application is used by medical personnel to access the central database and to perform detailed regular, periodic or on request health status assessments. Various expert plug-ins will be available to support health diagnosis activities and assessment of specific health problems. III. INTELLIGENT SENSOR IMPLEMENTATION
Intelligent sensors consist of two major subsystems: control (Intelligent Sensor Control unit - ISCU) and sensing. In Figure 2, our implementation of the control subsystem is presented. A micro controller with a short-range wireless interface and an A/D converter are the core components of a control subsystem. A memory module can be attached to the micro controller when an extension of the micro controller's built-in memory resources is required. The micro controller gathers sensor data via the A/D converter and temporarily stores it in the local memory. It also implements the client side of the XMLSens communication protocol. The details of the protocol are given in Section VI. We used AtMegal28L micro controller in our implementation. It has 128kbytes of RAM and 4kbytes ROM with built-in RS-232 I/0 ports and as such provides enough processing and expansion resources for health care applications. A 12 bit A/D converter is used. However, the micro controller uses only the most significant 8 bits. The Bluetooth wireless technology is used in our prototype to establish communication between an intelligent sensor and a patients control unit. We found that the Bluetooth is the most appropriate communication interface for this purpose at the moment. It supports adhoc detection of available sensors, throughput is sufficient for the majority of health care applications and, from the user point of view the most important, it is widely available in mobile phones. Hence, patient control units can be implemented as an application on a mobile handset that simplifies the system and reduces the number of devices a patient has to wear. In the future, other radio technologies like ZigBee could be used instead of Bluetooth. In order to control a Bluetooth interface, the micro controller has to have access to a Bluetooth protocol stack. Two options are possible: a stack can be embedded in the micro controller or a Bluetooth module with the full builtin stack can be used. Integration and porting of a Bluetooth protocol stack onto the target environment is usually rather complex procedure and requires 1020kbytes of memory which can be significant in an already memory constrained environment. In addition, this option requires a very good knowledge of all Bluetooth parameters and in particular of the Bluetooth API that makes it hard to implement, but at the same time gives a high level of control over the Bluetooth interface. We opted for the second option and have used TDK's blu2i Bluetooth module. This module comes with its own
IV. MPATIENT IMPLEMENTATION
The mPatient subsystem is implemented as an application on a SonyEricsson P900 mobile phone. This phone has been chosen due to the following characteristics: it is possible to develop user applications with access to phone's communication interfaces using either JAVA or C++ programming languages; JSR82 API required to control the Bluetooth functionality from a J2ME application is supported (this is one of the essential requirements of the mSens system); a large screen able to display gathered measurements with the required clarity; significant processing capability; large built-in memory resources with a possibility for expansion which makes storage of health measurements for a prolonged periods of time possible. The mPatient subsystem is responsible for interaction with the ISC units, mobile medical personnel and the central database. During a system initialization, this subsystem discovers available ISC units using Bluetooth discovery methods. Then, it establishes communication paths with the discovered ISCUs and gathers descriptions of available sensors using the XMLSens protocol. Sensors' descriptions are stored locally and are forwarded to the central database. Based on patient's instructions or instructions received from the database, required measurements are initiated. Received measurements are stored in phone's memory, displayed when requested and forwarded according to the defined rules to the central database or to mobile medical personnel. Single measurement values (for example, temperature and blood pressure measurements) can be transferred using SMS or MMS messages. Larger amounts of data (for example ECG) have to be transferred using TCP connections over HTTP. This method has to be used when critical data is being transferred to ensure higher transfer priority and reliability. In our prototype, the mPatient application is implemented as a JAVA midlet (J2ME platform). 81
EUROCON 2005
Serbia & Montenegro, Belgrade, November 22-24, 2005
4 t-A
41.UL%
E... F,
us .
04
-L-
For.
--!E-
K) Ur
.,A- GNb
311W
Figure 2 Intelligent Sensor HW implementation: control subsystem We have chosen JAVA over C++ because of the easier portability between different mobile phone models (in particular between SonyEricsson and Nokia phones due to different GUI frameworks used by C++, namely UIQ and Series6O). C++ implementation provides better support for interaction with the underlying Symbian system (for example access to the phone's file system, control of communication parameters, available communication methods, etc.), but we believed that J2ME environment could support the required functionality. However, JAVA implementation proved to be rather troublesome, especially in regard to the interaction with the Bluetooth interface. This interaction has caused substantial implementation problems due to instability and intermittent errors that were hard to explain and resolve. For example, application occasionally freezes during a Bluetooth discovery process, it is not always possible to break a Bluetooth connection from the application, the RMS (Record Management Store) used by J2ME midlets to permanently store data is rather slow which has an impact on the overall response time of the system etc. Synchronization of threads has also proved to be very cumbersome and a frequent source of problems. An additional problem that relates to the way J2ME is supported by Symbian is the fact that once the phone keyboard is closed, J2ME applications cease to run which obviously represents a significant problem for continuous health monitoring applications. The overall conclusion is that J2ME framework on mobile phones is still not quite capable of supporting demanding applications that extensively utilize external communication interfaces to transfer substantial amounts of data and require frequent access to phone's memory resources like the mPatient does. Functionality of a mobile doctor's unit is very similar to the functionality of a patient's control unit and is not described separately in this paper.
V. CENTRAL REPOSITORY IMPLEMENTATION The central database permanently stores all relevant users' data: general patients' and medical personnel's information (names, contact details), patients' history of diseases, etc. as well as the current health diagnosis, recommended treatment (prescriptions), sensors currently in use and of course the health measurements. In our prototype, the database is implemented as an Oracle 9i
database. Users communicate with the database via a proxy servlet over a GPRS/UMTS data connection, utilizing HTTP protocol to transfer mSens protocol messages. The servlet parses these messages and invokes the appropriate database procedures to store or retrieve required data. It is also responsible for establishment of a communication path between a mPatient and a mDoctor subsystems when mobile medical personnel need to remotely control a patient's subsystem. Each time a new sensor is discovered by the mPatient subsystem, it notifies the servlet/database about this event and forwards the sensor's XML description. The description is then stored and is used in the later stages to correctly store or present gathered measurements.
VI. SUBSYSTEMS INTERACTION After a mPatient subsytem has established Bluetooth connections with the discovered ISCUs, a local sensor query use case is performed (Figure 3). The mPatient subsystem sends a Get Sensor List message to all ISCUs. They reply with GetSensorListResponse messages. This message contains descriptions of all sensors (sensor profiles) controlled by respective ISCUs. The description is in XML format to provide easy support for various types of sensors with a number of different parameters. Based on the received sensor descriptions, corresponding objects with appropriate attributes are created by the mPatient
82
sample (integer, float, etc.), compression protocol, sequence of digits, video, audio, etc.
application to facilitate subsequent communication with physical sensors.
Message ID
customQuery against attribute
Description information is used to correctly receive and forward sensor data. All sensor descriptions are forwarded to the central database and measurement instructions (doctor's recommended measurement types, similar to drug prescriptions in use today) are received in a GetDataInstruction message. These instructions contain information on which type of measurements is required and how regularly the results should be forwarded to the database. XML is used again to allow flexibility in definition of required measurements and forwarding rules. Available sensors and their main characteristics can also be displayed by the mPatient and mDoctor applications so that doctors can define new or modify previously defined rules for measurement collection or patients can define their own measurements (for example, to monitor workout progress). Based on the received "prescription", the mPatient application selects appropriate sensors and forwards GetData messages to them Figure 4. raw data + data
a
REFERENCES [1] S. Krco, "Health care sensor networks - application and protocols", Ad Hoc & Sensor Wireless Networks Journal, Vol.1, January 2005. [2] B. Woodward, R.S.H. Istepanian, C.I. Richards, "Design of a Telemedicine System Using a Mobile Telephone", IEEE Transactions On Information
imPatient
g/ Self-describing data
a
VII. CONCLUSION Mobile health monitoring devices are in their infancy stage today and are not deployed or used on a large scale yet. However, the benefits and advantages of such systems are huge which in a combination with the increased level of the end users' familiarity with the technology and the overall quality of life requirements present a guarantee the personal health monitoring systems will become a part of the mainstream health services in the coming years. The mSens prototype described here answers the basic questions in regard to the ability to implement a usable system from both user and technology point of view. The complete system remains to be tested, evaluated and improved in a real life environment.
profile binding
GetDatalnstruction (sensorld) /
' Transmit * Data Data Format Mode Format
For prototyping purposes, an ECG sensor is supported only, it is not possible to change defined sensors data collection instructions and periodic forwarding of measurements is supported only (no event trigerred data transmission). ISCUs transmit sensor data in the GetDataResponse messages. These messages consist of a message header, sensor ID and sensor data. When a mPatient unit receives this message, it analyzes the message using a previously stored sensor profile and stores data in an appropriate structure. ISCU will continue to send gathered data according to the defined rules received in the GetData message. In the case of periodic transmissions, like in our prototype, data collection ceases when ISCU receives a GetDataStop message.
Figure 3 Local Sensor Query use case
Users
Transmit Mode
Figure 5 GetData message description
Sensorld
Users
Sensor ID
II
ISCU
Figure 4 Data Gathering use casse The structure of a GetData message is g;iven in Figure 5. The messageID (e.g. ID = 2) an d the list of sensorIDs are mandatory fields. The sens ,orlDs field defines which sensor the data is required froim. For each sensorID field, a TransmitMode and a DataF Iormat fields are defined. The TransmitMode field is an XML string that defines when and how often sensor mleasurements should be transferred to the mPatient unit. T ransmission periods, events definitions that could trigger a transmission and transmission duration are s,ome of the possible parameters. DataFormat also utiliz(es XML to define the data format that has to be useed for data transmission. It defines the size of each nneasurement
Technology In Biomedicine, Vol. 5, No. 1, March 2001. [3] E. Jovanov, A. O.Donnel, A. Morgan, B. Priddy, R. Hormigo, "Prolonged Telemetric Monitoring of Heart Rate Variability Using Wireless Intelligent Sensors and a Mobile Gateway", Proc. of the Second Joint EMBS/BMES Conference, USA, October 2002. [4] D. Konstantas, V. Jones, R. Herzog, "MobiHealth: innovative 2.5 / 3G mobile services and applications for healthcare", IST Mobile & Wireless Telecommunications Summit 2002, June 2002 Greece.
83
