Student Presentation #3: Sensor Networks for Biomedical Applications

1. Student Presentation #3: Sensor Networks for Biomedical Applications

2. Presentation Overview • Motivations • Representative Tour of Current Work • HealthGear • AMON: Advanced Care and Alert Portable Telemedical Monitor • Shoe-Integrated Gait System (SIGS) • Wireless PDA-Based Physiological Monitoring System for Patient Transport • MIThril 2003 • WearARM • Smartshirt • Patient-Centric Network • University of Alabama at Huntsville • In-Depth look at • CodeBlue • Conclusions

3. Motivations • “The U.S. healthcare delivery system does not provide consistent, high-quality medical care to all people” –Institute of Medicine • Healthcare spending is the U.S. rose from $1.31 trillion in 2002 to $1.42 trillion in 2003, which is largest increase in a decade • 14.1% of GDP accounted for by healthcare spending in 2001. This is also on the rise. • 98,000 people die each year due to medical errors in hospitals. This is more than car crashes, breast cancer, or AIDS • 80% of deaths in the US are caused by seven major diseases: heart disease, cancer, diabetes, arthritis, chronic bronchitis, influenza, and asthma. • For all of these health conditions, “early, systematic intervention would be highly beneficial” Enhancing the Quality of Life Through Wearable Technology, Park et al.

4. HealthGear • Microsoft Research • The design goal was to monitor blood oxygen levels in real time by means of a non intrusive wireless sensor, with the intended use of monitoring sleep apnea. • A blood oximeter is sampled at 3Hz and the data is transmitted via Bluetooth to a cell phone, which is the central processing unit.

5. HealthGear (contd.) • This was a relatively easy goal • Sensor must last 12 hours or less before recharging • Subject is asleep, so limited mobility requirements • SpO2 levels change very slowly, so low sampling rate of 3Hz • Sleep apnea can be easily identified by setting a threshold deviation from baseline.

6. HealthGear (contd.) • That being said, the results were excellent.

7. HealthGear (contd.)

8. HealthGear (contd.) • To determine baseline, a sliding window of 5000 samples is maintained and the average of the top 5% of samples is calculated. • Multithreshold analysis allows detection of events of varying severity • In addition to simple threshold checking, spectral analysis of the data was also performed. • 5000 samples are split into 6 groups of 834 samples. • 1024-point FFT is taken of Hamming-windowed data • Resulting PSD shows peaks between .015Hz and .04Hz. Presence/amplitude of peak determines occurrence/severity of apnea events

9. AMON: Advanced Care and Alert Portable Telemedical Monitor • Multiparameter monitoring in one device worn on wrist • Swiss Federal Institute of Technology • Multiparameter monitoring of patients with pulmonary disorders • Oxygen Saturation (SpO2), blood pressure, ECG • Activity Recognition via accelerometer • Online Analysis and Emergency Detection • Flexible Communication Interface • All-in-One Wrist-Worn System

10. AMON (contd.) • Wrist monitoring device stores and analyzes data and forwards it periodically (8 hours) or in case of abnormal measurements via GSM to MMC • Forwarding can be Short Message Service, virtual switched communication channel, or ftp type protocol

11. AMON (contd.) • SpO2 monitoring measures changes of absorption of two optical wavelengths (660nm 880nm) during pulsation • Heart rate could be measured • Blood oxygen levels could not be measured to satisfaction • ECG consists of three electrodes that would normally be on both arms and right leg. These are instead all on the wrist. • Heart rate measurements were successful. • More sophisticated online analysis (QRS complex width, RR distance, QT interval) failed. • Temperature sensor abandoned. • Blood pressure yielded good systolic results but poor diastolic results

12. AMON (contd.) • Activity measurement via accelerometer proved difficult due to placement on wrist. • Typing excited higher peaks than walking, although frequency analysis yields good results.

13. AMON(contd.) • Power analysis claims average current consumption of 25.4mA • For 1.25 AH LiION rechargeable battery, this yields just over two days of use.

14. AMON Conclusions • Several sensors showed poor performance due to choice of All-in-One Wrist-Worn design. • GSM based communication provides privacy, encryption, reliable network at reasonable power. • Online analysis and emergency detection provides good results but is not robust (enough) for high sensor noise • Power performance is, at least nominally, sufficient. • AMON does prove feasibility, although superior sensing technology required.

15. Shoe-Integrated Gait System (SIGS) • Harvard/MIT • Top level requirements of such a system • Attach removably to patient’s shoes • Effect no change in gait • Characterize motion of both feet • Wireless transmission of data • Analysis of data in real time

16. SIGS

17. Wireless PDA-Based Physiological Monitoring System for Patient Transport • National Taiwan University

18. PDA (contd.) • Mobile Unit • Consists of a Vital-signs signal acquisitions module coupled to an HP iPAQ via RS-232 • Vital Signs Acquisition Module • 3 Lead ECG, amplified and processed • Blood oximeter signals separated into AC and DC components which can be used to calculate pulse rate and oxygen saturation • These signals are inputs to an 8 bit microcontroller, which digitizes them and samples at 200Hz before transmitting via serial port at 115.2kbps

19. PDA (contd.) • PDA program written in c++ has a real time display of vital signs

20. PDA (contd.) • Transmission from iPAQ to management unit via 802.11b • High data rate (11Mbps) • Reliable within tens of meters • Privacy concerns met • SSID, MAC address filtering, WEP • 128 bit AES algorithm used for end-to-end encryption • No interference with other medical equipment • Relatively high power consumption of 802.11 limits worst case battery life to 70 minutes.

21. MIThril 2003 • Uses a StrongARM processor based PDA similar to the PDA based example out of Taiwan • Not necessarily geared towards medical applications. There a couple of sensor boards, one of which is for physiological sensing. • More substantial developments in software • Enchantment Whiteboard- a client/server model where clients post and read information on a whiteboard server • Clients can subscribe to various parts of the whiteboard, in order to receive updates when changes occur. • Clients can lock parts of whiteboard so that only certain clients can read them • Enchantment Signal System- In order to facilitate transmission of high bandwidth signals, point-to-point communication between two nodes can be establish via the Whiteboard. • Latencies are introduced by this but can be resolved by timestamping. The increased latency was generally small enough to enable real-time responsiveness in user interactive applications.

22. MIThril 2003 (contd.) • Real-Time Context Engine abstracts process of sensing, modeling, and inference as shown below: • Application as a rehabilitation aid in Wearable Feedback Systems for Rehabilitation, Sung et alia and as an engine for Activity recognition in Activity Recognition From User-Annotated Acceleration Data, Bao, et alia.

23. WearARM • Developed at Swiss Federal Institute of Technology • Distributed Architecture combines a core module consisting of a low power StrongARM processor, SDRAM, Flash and VGA DAC with three other modules • Basic Module supplies power to the core, and contains other peripherals • Peripheral Module contains baseT 10 Ethernet for body area networking, audio systems for speech control and audio output • DSP module contains low power TI DSP chip for computationally intensive operations • Standby and sleep modes as well as dynamic voltage scheduling enable low power operation • Flexible connections of credit card sized components makes integration with everyday clothing easy.

24. Smartshirt • Georgia Tech School of Textile and Fiber Engineering • A shirt with a “flexible bus,” a patchwork of optical and conductive wires integrated into the material, which connect sensors in any desired location to the Smart Shirt Controller, which enables data transport through appropriate communications channel. • Termed a “wearable motherboard”

25. Patient-Centric Network • MIT • Multi-tiered network architecture for monitoring patients.

26. Patient-Centric Monitoring (contd.) • Each sensor has a gateway (wearable device, bedside machine, . . .) that interfaces between the sensor protocol and the technology use in the rest of the network • To enable data stream fusion, gateways must timestamp data. Therefore, time synchronization is required. Generally a millisecond level sync would be sufficient. • On a shared, general-purpose machine, there exists a proxy, or chained proxies, for each sensor, which is responsible for all processing of its data. • Centralized management via this machine enables detections of errors. Due to the relatively small number of sensors, centralization does not cause a scaling problem.

27. University of Alabama at Huntsville • A rich set of wireless intelligent sensors including ECGs, accelerometers, pulse oximeter, heart rate monitors, nostril symmetry monitor, etc. implemented on MSP430 processors. • Wireless Gateways enabled via PDA, Zigbee radios, etc. • http://www.ece.uah.edu/~jovanov/whrms/

28. CodeBlue – Overview • Harvard University http://www.eecs.harvard.edu/~mdw/proj/codeblue/ • Intended to act as an “information plane” tying together a wide range of wireless devices used in medical settings • Combined hardware and software platform for medical sensor networks • Medical sensors based on Mica2/MicaZ and Telos mote designs • Pulse oximeter • EKG • Motion-activity sensor • Publish/subscribe routing • 30-node sensor network testbed • Demonstrate scalability and robustness as queries, data rates and transmitting sensors are varied • Effects of node mobility, fairness and patterns of packet loss

29. CodeBlue – Requirements • Relatively high data rates • less than 1 Hz to 1000 Hz or more • Reliable communication • loss due to congestion or node mobility would be problematic • Multiple receivers • PDAs carried by doctors and nurses • Device mobility • Assume both patients and caregivers are mobile • Security • U.S. law mandates that medical devices meet the privacy requirements of the 1996 Health Insurance Portability and Accountability Act (HIPAA) • Cannot make use of traditional in-network aggregation • Not generally meaningful to combine data from multiple patients

30. CodeBlue – Sensor: Pulse Oximeter • BCI Medical Micro-Power Pulse Oximeter (39 mm × 20 mm with a current draw of 6.6 mA at 3 V) • Reports heart rates in the range 30–254 bpm and SpO2 values from 0 to 99% • Incorporates the Mica2/MicaZ 51-pin connector, the two headers for the BCI board, and a DB9 connector for the finger sensor TinyOS module on the mote controls the BCI hardware (can be reset using two digital I/O pins from the mote) Parses the serial protocol to determine HR and SpO2 BCI module requires about 20 seconds to acquire a new waveform and report vital sign data If the finger sensor is detached from the patient, the board reports an error condition using out-of-range vital sign values

31. CodeBlue – Sensor: EKG • Provides continuous EKG monitoring by measuring the differential across a single pair of electrodes • TinyOS component samples the EKG signal at a configurable frequency (typically 120 Hz) • Texas Instruments INA321 CMOS instrumentation amplifier (factor of 5) • Additional operational amplifiers with passive components provide enhanced filtering • High-pass feedback filter to dynamically correct any DC shift • Signal passes to an op-amp that provides further amplification and acts as a low-pass filter • Evaluation of the output by a clinical cardiologist confirmed that it was comparable to that of commercial EKG machines.

32. CodeBlue – Sensor: Motion analysis • Interfaces to the Telos mote • 2g/6g 3-axis accelerometer (STMicroelectronics model LIS3L02AQ) 100 Hz sample rate • single-axis gyroscope (Analog Devices ADXRS300) 100 Hz sample rate • EMG (MP- 1A.20.A0DM.60 from Motion Lab Systems, Inc.) 1kHz sample rate The board includes a number of operational amplifiers to enhance signal quality together with voltage conditioning ICs to power the gyroscope and passive filters to eliminate noise. Signals are routed through the board to five ADC ports on the Telos mote Data is captured to the mote’s EEPROM and relayed using a reliable communication protocol to a nearby base station for logging Timestamping used to correlate signals across multiple sensor devices

33. CodeBlue – Pluto mote • Existing mote platforms are good for demonstrations, but large battery packs and protruding antennas are suboptimal for medical use • Sacrifice expandability and battery life in favor of a lightweight, miniaturized design that fits within a convenient plastic enclosure Based on Telos Rev B (“Tmote Sky”) TI MSP430 microprocessor and ChipCon CC2420 radio (uses a gigaAnt surface-mount antenna) Tiny rechargeable 120 mAh lithium polymer battery (25 mA, 5 hour life @100% duty) Mini-B USB connector is used for programming and to recharge the battery (board features built-in recharge circuitry) No software changes are required

34. CodeBlue – S/W Architecture • CodeBlue is implemented in TinyOS and provides protocols for integrating wireless medical sensors and end-user devices such as PDAs and laptops

35. CodeBlue – Sensor Interface • GenericSensor interface is used to abstract the details of acquiring data from each sensor type. ( analogouts to TinyOS ADC interface) • Data is requested with a call to getData() • dataReady() event is signaled upon completion Pointer is returned to an internal memory buffer containing the sensor data (size based on sensor type) StdControl interface allows associated hardware to be powered on or off

36. CodeBlue – Localization: MoteTrack • RF based location and tracking • B1, B2, and B3 are beacon nodes, which broadcast beacon messages at various frequencies and transmission powers (f1p1, ..., fipj ). Each beacon node stores a subset of all reference signatures. M is a mobile node that can hear from all three beacon nodes. It aggregates beacon messages received over some time period into a signature. The areas enclosed by perimeter lines indicate the reachability of beacon messages from the corresponding beacon node. The dots denote the known locations where reference signatures were collected. http://www.eecs.harvard.edu/~konrad/projects/motetrack/

37. CodeBlue - Routing • Publish/subscribe routing framework • Sensors publish relevant data to a specific channel and end-user devices subscribe to channels of interest • Decouples the concerns of devices generating data from those receiving and processing it • Considerations to take into account • Sensors should not publish data at an arbitrary rate, communication model should either specify requested data rates or give publishers the ability to locally filter sensor data before publication • Publishers and subscribers are not necessarily within radio range, some form of multihop routing is necessary • Communication layer should take mobility into account when establishing routing paths

38. CodeBlue – Routing (cont.) • Adaptive Demand-Driven Multicast Routing (ADMR) protocol • TinyADMR (equivalent to their Active Message counterparts in TinyOS, except that the channel ID replaces the destination mote ID) • Publish • Subscribe • Leave • Send • Send-Done • Receive

39. CodeBlue – Routing (cont.) • ADMR establishes multicast routes by assigning nodes to be forwarders for a particular channel • A forwarder rebroadcasts any messages that it receives on a given channel • duplicate suppression is used to avoid multiple transmissions • Nodes are assigned as forwarders through a route discovery process that is initiated when a patient device requests to publish data • Every node maintains a node table indexed by the publisher node ID • Each node table entry contains the path cost from the publisher to the current node, as well as the previous hop in the best path from the publisher • Each node knows the best (lowest cost) path from each publisher to itself

40. CodeBlue – Discovery Protocol • A discovery protocol allows end-user devices to determine which sensors are deployed in a CodeBlue network • ADMR supports a special broadcast channel that uses a simple controlled flooding mechanism to deliver a message (unreliably) to every node in the network • Nodes periodically publish metadata, including node ID and sensor types, to the broadcast channel • Receiving devices can subscribe to the broadcast channel to receive this information • Metadata information is static and is not updated frequently (~ 30 seconds)

41. CodeBlue – CBQ • CodeBlue Query (CBQ) layer allows receiving devices to establish communication pathways by specifying the sensors, data rates, and optional filter conditions that should be used for data transfer • S: set of node IDs that should report data for this query • Tau: is the sensor type • Chan: ADMR channel to publish results to • Rho: sampling rate • C: total number of samples to retrieve from each node • p: filter predicate • E.g. • Specifies that nodes 3 and 7 should report their SpO2 data to channel 38 every second, using the filter predicate p.

42. CodeBlue - GUI • Java-based GUI • Easy for medical personnel to use • Provides enough detail on patient status and location to identify trends

43. CodeBlue - Results • Indoor testbed of 30 MicaZ motes, distributed over 3 floors of Harvard’s Computer Science building • Virtual sensors used to generate data at a constant rate • Evaluate system with the following in mind • Attempt to measure scalability related properties: • What is the effect of increasing the data rate generated by each sensor device? • What is the effect of increasing the number of senders? • What is the effect of increasing the number of receivers? • Attempt to demonstrate overall fairness • Effects of latency and jitter • Effects of mobility

44. CodeBlue – Results (data rate) • Number of received packets divided by the number of transmitted packets for three separate sender-receiver pairs • Single-hop case perform very well • Multi-hop case degrades substantially • forwarding nodes must compete for bandwidth with both the upstream and downstream forwarders • Increased reception rates cause packet queues to fill forcing packets to be dropped. • Interfering traffic adversely affects reception ratios on testbed (even when no transmissions are dropped) • likely due to collisions caused by hidden-terminal effects.

45. CodeBlue – Results (1 to 10 senders) • The results are encouraging for low data rates (below 5 packets per second per sender) • Reception ratio is above 62%, even with 10 senders • Vital sign sensors (pulse oximetry, blood pressure, heart rate) only need to transmit data once per second • suggests that the system could scale to a large number of devices with a modest data generation rate

46. CodeBlue – Results (3 receivers) • Receivers are no longer within one hop from the first sender so degradation is observed as the data rate increases (1 sender) • The maximum aggregate bandwidth of 10 senders and 3 receivers is 120 Kbps (40 Kbps per receiver) This is consistent with the singlehop throughput of Telos motes with the standard TinyOS CC2420 radio stack • These numbers are far below the nominal 802.15.4 channel capacity of 250 Kbps due to MAC and protocol overheads

47. CodeBlue – Results (fairness) • 6 senders (each generating data at 1 packet per second) and 3 receivers. The path hop counts for each route varied from 1 to 6 • Reception ratio across all pairs is roughly equivalent • Mean of 83% and a standard deviation of 12% • One case logged the reception ratio less than 60%

48. CodeBlue – Results (latency & jitter) Packet jitter is the number of consecutive dropped packets for a given sender-receiver pair No jitter is observed for 86% of the packets, 9% of packets experienced a jitter of 1, and 5% of the packets experienced a jitter greater than 1 Maximum jitter observed is 23 packets • End-to-end latency for several multihop paths of up to 7 hops at a data rate of 1 packet per second was less than 200 ms • RTT is problematic in ADMR framework • Based on timestamped debug messages generated by senders, receivers and forwarders (accuracy is questionable due to context switching)

49. CodeBlue – Results (mobility) • 3 fixed nodes as patient sensors transmitting data at 5 packets per second. • Senders were widely distributed throughout the building • Single receiver node attached to a laptop acted as a roaming node • Reception ratio for each of the 3 senders is averaged over 60 second windows • Results show that ADMR deals gracefully with node movement for “typical” mobility rates

50. CodeBlue – Results (multiple transmit) • For low data rates (< 15 pps), multiple transmissions per packet increases rec. ratio from 63% (with 1 Tx) to over 98% (with 5 Txs) • At larger data rates increased load causes network saturation and rec. ratios drop