Implementing and Validating an Environmental and ... - IEEE Xplore

Fifth International Conference on Information Technology: New Generations

Implementing and Validating an Environmental and Health Monitoring System Marco Messina, Yen Yang Lim, Elaine Lawrence, Don Martin Faculty of IT, University of Technology Sydney PO box 123, Broadway 2007 NSW, Australia E-mails: messina|[email protected] brian.lim\[email protected]

Frank Kargl Institute of Media Informatics, Ulm University, 89069 Ulm, Germany E-mail: [email protected]

integrated with the commonly used Mica2, MicaZ and Telos motes. In our architecture, we deploy MicaZ motes as wireless nodes, BCI pulse oximeters as medical sensor boards, the same used by the CodeBlue project, and MTS310 sensor boards as environmental sensors. These sensors collect the patients’ data and transmit them to local medical databases containing medical records or to a remote healthcare server. To address these requirements, the CodeBlue protocol and middleware framework implemented in TinyOS [13] offers protocols for device discovery, publish/subscribe multihop routing and an easy-to-use graphical user interface (GUI) which enables medical staff to request data from individuals or groups of patients. In this paper we describe the design and implementation of enhancements to the CodeBlue software and hardware. Our effort focused on two aspects: the wireless sensor network side by integrating environmental sensors that were previously not supported by the CodeBlue platform, in order to set up a combined environmental and medical monitoring system; and, on the backend side of the architecture, by implementing an SNMP-proxy connection in order to make the data easily available. The rest of this paper is structured as follows: the next section describes in detail the health monitoring system architecture. Section III reports on the series of scenarios tested on the system in the laboratory. In this section the system is evaluated and validated according to the analysis of the data collected during the laboratory testing. Finally, Section IV offers some concluding thoughts and future enhancements of the architecture.

Abstract In this paper the authors describe the implementation and validation of a prototype of an environmental and health monitoring system based on a Wireless Sensor Network (WSN). The solution proposed for our system combines environmental and medical sensors in order to monitor both the surrounding area of the patient and the patient’s health status simultaneously. This feature would allow a comprehensive understanding of the patient’s condition by the specialist caring for the subject. Another key feature of the system is the development of an architecture which provides an easy, viable, cheap and effective way for connecting our environmental and medical sensor network of MicaZ motes to the outside world using Simple Network Management Protocol (SNMP) version 3. A series of experimental scenarios were developed and implemented in a laboratory setting; firstly for evaluating the reactivity of the monitoring system to changes and secondly for understanding the reliability of the data obtained for benchmarking purposes. The conclusion considers the implementation of future improvements to the health monitoring network by introducing new sensors and location tracking capabilities, and by integrating alarm triggering algorithms and advanced security techniques.

Key words- Medical sensor networks, CodeBlue, SNMP, health monitoring.

1. Introduction The health sector is currently one of the most attractive targets for Wireless Sensor Network (WSN) applications. A health monitoring application, for example, allows health professionals (doctors, nurses, etc.) in a hospital or clinic to constantly monitor patients fitted with tiny, wearable sensors capable of collecting sensitive, vital health information in real-time. In this context, the most recent and perhaps the most promising complete proposal, is the CodeBlue prototype medical sensor network platform [8]. CodeBlue utilizes a range of medical sensors

978-0-7695-3099-4/08 $25.00 © 2008 IEEE DOI 10.1109/ITNG.2008.119

2. Architecture 2.1. Overview The architecture of the health monitoring system, as displayed in Figure 1, comprises the WSN connected via a gateway mote to the gateway PC. The motes are equipped with medical and/or environmental sensors. The sensor

995 994

network transmits gathered data via the CodeBlue protocol [4] to the gateway mote, which redirects the data to the local host for a first data analysis. On the Gateway-PC, the CodeBlue GUI displays the gathered data, the network topology and the Mote-equipped patients (see Figure 3). The data is stored in log files and made available to remote systems via an SNMP-proxy. Using only logfiles, we are even able to replay earlier experiments to SNMP clients in order to test our system when no patients are available.

involved in developing tools or systems for patient monitoring based on WSNs. Examples include the Advanced Health and Disaster Aid Network (AID-N) from Johns Hopkins University for improving the way to provide emergency care in prehospital situations. Electronic triage tags with sensors continuously monitor the vital signs and locations of patients until they are admitted to a hospital (VitalMote Technology) [6]. The department of Computer Science, University of Virginia is developing AlarmNet, an architecture for smart healthcare, continuous monitoring of assisted-living and independent-living residents based on mote technology [1]. Other examples include BigNurse [2] or the Motecare system [9]. Finally, Harvard University has devleoped CodeBlue, a platform based on mote sensors network technology useful for a range of medical applications, including pre-hospital and in-hospital emergency care, disaster response, and stroke patient rehabilitation [10]. This is the platform we adopted for our prototype. The system is based on MicaZ motes. The medical sensors adopted were pulse oximeter sensors from BCI, Inc. (see Figure 2). The device consists of a standard finger or ear sensor, a pulse oximetry module (BCI Micro Power Oximeter board) and a mote. The pulse oximeter module has a serial interface that relays SpO2 (blood oxygen saturation), pulse, and plethysmogram waveform data to the MicaZ node. The pulse oximeter mote device periodically transmits packets containing the measured samples. For environment sensors we used the MTS310CA which is a flexible sensor board with a variety of sensing modalities. In our system we deployed light and temperature sensors, which were integrated into the CodeBlue system.

Figure 1. WSN Health Monitoring Architecture We argue that our design has two significant advantages: first, introducing environmental sensors that collect context information will help in analysis of the medical data. When, e.g., a patient is doing sports, medical parameters like heart rate or O2 saturation have to be interpreted differently compared to the same person sleeping in bed. Second, making available the data via SNMP allows us to use existing network management tools with only slight modifications for medical monitoring. In essence, patient monitoring and network monitoring is not too different. It is all about collecting period data samples (like link usage or heart rate) from a large number of entities (like switches or patients), interpreting this data, triggering alarms or predicting trends. Using SNMP, one monitoring and analysis station can supervise a large number of sensor networks from a central place.

Figure 2. Pulse oximeter device [1]

2.3. CodeBlue Enhancements

2.2. Wireless Sensor Network

We extended the CodeBlue system so that motes were able to collect light and temperature values and transmit them as additional channels to the CodeBlue GUI, where this data can be displayed in addition to the medical values. The screen shot in Figure 3 shows on the left hand side the improvements added to the basic version of the

Key WSN devices in the remote healthcare monitoring domain are tiny battery-powered sensors called Motes. There are a variety of mote designs, e.g. the Mica motes from University of California, Berkeley. Motes organize themselves into a wireless network, sharing data with one another and with computers, embedded devices, or PDAs. Already, a number of commercial and research groups are

995 996

CodeBlue GUI. Patient #102 is able to collect environmental data, namely light and temperature readings. On the right hand side of the GUI temperature and light graphs have been added. The topology on the center right side remains the same; it shows the base station with a red cross and the two patients sensors forming a wireless sensor network. The diagnostic panel at the bottom left is used mainly for debugging purposes.

SNMP allows for multiple agents (devices) to talk to multiple managers. This allowed us to have multiple managers polling the Gateway-PC for the required information without increasing the load on the WSN side. Besides, SNMPv3 supports encryption and provides endto-end point security [6, 3].

2.5. SNMP Clients Each agent in an SNMP-managed network maintains a local database of information relevant to network management, known as the management information base (MIB). An SNMP-compliant MIB contains definitions and information about the properties of managed resources and the services that the agents support. The manageable features of resources, as defined in an SNMP-compliant MIB, are called managed objects or management variables (or just objects or variables) [12]. Each object in the MIB has an object identifier (OID), which the management station uses to request the object's value from the agent. An OID is a sequence of integers that uniquely identifies a managed object by defining a path to that object through a tree-like structure called the OID tree or registration tree. When an SNMP agent needs to access a specific managed object, it traverses the OID tree to find the object [12]. We plan to define an own range of OIDs for representing medical values. A MIB browser is a simple SNMP client allowing viewing of the hierarchical tree of the SNMP MIB variables and displaying them as values or graphs. Figure 4 shows the graphical view of the light sensor.

Figure 3. Screen Shot of CodeBlue showing environmental data The sensor data collected by the network and shown in the GUI is stored continuously in log files. The log file stores records consisting of a time stamp, the patient and sensor ID, and the sensor value: : , = Once the data is stored in the log file, the SNMP-proxy makes it available via the Simple Network Management Protocol (SNMP v3). Alternatively, the proxy can also replay older logfiles for testing purposes.

2.4. SNMP-proxy As motes have extremely limited processing power, battery life and transmission budgets, the implementation of TCP/IP on a mote, while possible [7,5], would create additional overhead that would significantly reduce battery life. By creating an SNMP-proxy which acts as an IPbased Data Delivery Unit (DDU) in order to bridge the gap between non-TCP/IP sensor networks and the Internetbased monitoring systems, WSN monitoring and data collection can become an extension of already existing network management infrastructure (see Figure 1). For our current implementation of a DDU, we used SNMP4J [11] to provide data generated by the enhanced CodeBlue software.

Figure 4. Screen Shot of the MIB Browser Of course, more advanced clients should be considered, e.g. network management systems like HP Open View (now rebranded as HP Network Node Manager). Ultimately, such network management tools could evolve

996 997

to automated medical supervision tools that can even predict health problems.

This scenario aimed to investigate how the system would react to fast changes by inducing changes in heartrate with exercise. The changes in heart-rate which occurred between the resting and the walking stages were well detected. Smooth changes for the older female patient (#105) and steep changes for the younger male (#102) are recognized by the system quickly and accurately in response to physical activity changes during the test. Analysis of the complete log files showed that the data losses experienced were minimal.

3. Experimental Scenarios and Test Results In order to validate the architecture developed, the authors ran a series of experimental scenarios to be tested in the laboratory. The various scenarios allow for evaluating the reactivity of the monitoring system to environmental and physiological changes. Minor data losses were experienced but overall the system responded very well during the test bed experiments. The scenarios and results obtained for each of them are described next. The graphs show the results of the testing of the scenarios using six subjects ranging in age from twentytwo (22) to over sixty (>60). Two subjects were female and four were males.

Scenario 2: 4 minutes low lights and relaxing music, 2 minutes, of loud music and bright lights In this scenario we recorded the light readings, heart rate and oxygen saturation over a period of 6 minutes. In order to relax the subjects we had them listen to classical music on a computer for four minutes in a darkened room. Then the soundtrack was changed to loud music and bright lights were switched on for 2 minutes. We wanted to confirm that the system could monitor health measurements in response to an environmental change. In particular we wanted to detect if the elevated sound and bright lighting affected the heart rate after the person has been sitting and relaxing with soft music and low lights in order to understand the impact of external sources on the patient status.

Scenario 1: 1 minute resting, 2 minutes slow walking, 1 minute resting, 2 minutes fast walking. In the first scenario the subject attached the pulse oximeter to the finger and had the heart rate and oxygen saturation measured for a total of 6 minutes. For the first minute the subject was in a relaxed sitting position to establish the resting heart rate. During the next two minutes the patient walked slowly, and then spent one minute resting before finally walking quickly for the last two minutes of the scenario. The graph below plots the heart rate of the two patients monitored in this scenario: patient #102 is a male of 35 years old and patient #105 is a female of over 60.

Figure 6. Graph of pulse data from Scenario 2 The figure 6 above shows the heart rates of the same patients of the scenario 1. From this data set we can identify some data losses, more evident for the patient #102. Overall the system detected the correlated changes in the health and environmental measurements. For example, the system recorded the expected variation after 4

Figure 5. Graph of pulse data from Scenario 1 for 2 subjects

997 998

minutes, when the lights are switched on and the music changed to loud rock music. Only the patient #102, the younger male, experienced changes to his pulse when the environmental factors changed. The patient #105, the older female, did not exhibit any significant changes on the system during the session.

changes in the physiological state of the patient as he or she interacts with the game. The chosen computer game tests the player’s ability to park a car in a limited space. In our experiments we asked the patients to start on level 1 which requires a low skill level and suggested to the patients that they were expected to move up the levels to show advanced parking skills, such as avoiding pedestrians, animals and a series of other cars whilst attempting to park. We believed that the computer sounds generated by the computer game plus the anxiety to move up the levels had the potential to change the patients’ physiological data (see figure 8).

Scenario 3: 1 minute relaxing, 30 seconds deep breathing, holding breath as long as possible In this scenario we wished to detect the oxygen saturation (SpO2) level by performing breathing exercises including deep breathing and holding the breath for approximately half a minute. The aim is to evaluate the monitoring system by checking the SpO2 levels for a given patient in a controlled environment. The lowest value obtained was 83 percent by the younger male subject, patient #102 (Figure 7) which would appear to be appropriate.

Figure 8. Graph of pulse data from Scenario 4 As expected, the younger male patient #102, who seemed to be more involved with the game, exhibited fast and frequent pulse variation while playing the game. Regarding the oxygen saturation, both subjects were seated on chairs; therefore their breathing rhythm was constant indicating a relatively stable oxygen level during the entire session (see Figure 8). Minor data losses were experienced by the system.

Figure 7. Graph of oxygen data from Scenario 3 As can be seen on the graph, the patient #102 increases his oxygen level during deep breathing reaching his maximum level of 99 percent before starting to drop below 85 percent when holding the breath for the next 30 seconds. Overall, the pulse oximeter sensor was able to sufficiently measure the difference in SpO2 levels for each part of the scenario. The female patient #105 did not exhibit major changes to her oxygen level.

4. Conclusion and future study This study was set up in order to introduce the concept of combined medical and environmental monitoring and to evaluate the reliability of the data gathered by the environmental and health monitoring system. In our experiments data concerning heart rate, blood oxygen saturation, environmental light and temperature levels were gathered simultaneously in real time and with minimal data losses. Our studies indicated that the system behaved reasonably well as an environmental and health monitoring system. The refinement of our system will be of benefit in medical applications where patients need

Scenario 4: 1 minute relaxing, 5 minutes playing computer game In this scenario we monitored each subject resting for 1 minute and then playing a computer game. The goal is to evaluate the system’s ability to detect any small, frequent

998 999

monitoring continuously in various environments. For example, the system would be of value to assist nurses in a busy hospital environment. More particularly, the system would be of benefit for out-patient monitoring and for community-care nursing. It is not practical in those situations to assign a nurse for round-the-clock monitoring of patients. We plan to test the system by hospital trials in order to verify the reliability of wireless communication over a wider location with a denser network. One technical issue that needs to be resolved is to pursue total wireless connectivity among the standard finger or ear sensor, the pulse oximeter module (BCI Micro Power Oximeter board) and the mote. The patients would be better served if this connectivity was attained wirelessly for complete patient mobility. SNMP is a robust and well tested network management tool in the internetworking world. Further testing of its performance in the health monitoring world will be required to ensure its reliability and acceptability to the medical industry. In order to implement future improvements to the health monitoring network we aim to introduce new sensors such as cameras, ECG sensors as well as location tracking capabilities. We also plan to integrate alarm triggering algorithms and advanced security techniques in Wireless Sensor Networks which would be essential in a health monitoring environment.

[7] Harvan. M.”Connecting Wireless Sensor Networks to the Internet - a 6lowpan Implementation for TinyOS 2.0”, Master’s thesis, School of Engineering and Science, Jacobs University Bremen, May 2007. [8] Hill, J., Szewczyk, R., Woo, A., Hollar, S., Culler,D.E., and Pister , K.S.J. "System architecture directions for networked sensors," in Proc. the 9th International Conference on Architectural Support for Programming Languages and Operating Systems (Nov. 2000), pages 93–104. [9] Lubrin, E., Lawrence,E. and Felix Navarro, K.”An Architecture for Wearable, Wireless, Smart Biosensors: The MoteCare Prototype”, IEEE Proceedings of Mobile Computing and Learning Conference (MCL 2006), Mauritius, April 24 – 28, 2006. [10] Malan, D., Fulford-Jones, T., Welsh,M. and Moulton, S.An Ad Hoc Sensor Network Infrastructure for Emergency Medical Care, International Workshop on Wearable and Implantable Body Sensor Networks, April 2004. [11] SNMP4J, "The Object Oriented SNMP API for Java Managers and Agents. ," From: http://www.snmp4j.org/. [12] SNMP MIB, BEA Systems Inc., From: http://edocs.bea.com/snmpagnt/v210/mibref/1tmib.html (2001). [13] Shnayder, V., Chen, B., Lorincz, K.,Fulford Jones, T. and Welsh M., "Sensor Networks for Medical Care," Technical Report TR-08-05, Division of Engineering and Applied Sciences, Harvard University. From: ftp://ftp.deas.harvard.edu/techreports/tr-2005.html (2005).

References [1] AlarmNet., From: http://www.cs.virginia.edu/wsn/medical/index.html. (2007). [2] Bader, R., Pinto, M.,Spenrath,F., Wollmann,P., Kargl, F: ”BigNurse: A Wireless Ad Hoc Network for Patient Monitoring“. First Workshop on Location Based Services for Health Care, Locare'06, Insbruck, Austria, November 2006. [3] Blumenthal, U. and B. Wijnen, B. "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)," Network Working Group, Lucent Technologies (December 2002) [4] Chen, B., Muniswamy-Reddy, K. and Welsh, M. “Ad-Hoc Multicast Routing on Resource-Limited Sensor Nodes”, Proceedings of the Second ACM/Sigmobile Workshop on Multihop Ad Hoc Networks: from theory to reality (REALMAN'06), Florence, Italy, May 2006. [5] Douglas E. Comer, "Internetworking with TCP/IP," INTERNETWORKING with TCP/IP principles, protocols, and architectures (P. Hall, ed., 2000). [6] Gao Tia et al., "Vital Signs Monitoring and Patient Tracking Over a Wireless Network. From: http://www.jhuapl.edu/techdigest/td2701/Gao.pdf.," Johns Hopkins APL Technical Digest, 27:1 (2006).

1000 999