Student presentation 3 sensor networks for biomedical applications
1 / 52

Student Presentation #3: Sensor Networks for Biomedical Applications - PowerPoint PPT Presentation

  • Uploaded on

Student Presentation #3: Sensor Networks for Biomedical Applications. Presentation Overview. Motivations Representative Tour of Current Work HealthGear AMON: Advanced Care and Alert Portable Telemedical Monitor Shoe-Integrated Gait System (SIGS)

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Student Presentation #3: Sensor Networks for Biomedical Applications' - carver

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

Presentation overview
Presentation Overview Applications

  • 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

Motivations Applications

  • “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.

HealthGear Applications

  • 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.

Healthgear contd
HealthGear (contd.) Applications

  • 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.

Healthgear contd1
HealthGear (contd.) Applications

  • That being said, the results were excellent.

Healthgear contd2
HealthGear (contd.) Applications

Healthgear contd3
HealthGear (contd.) Applications

  • 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

Amon advanced care and alert portable telemedical monitor
AMON: Advanced Care and Alert Portable Telemedical Monitor Applications

  • 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

Amon contd
AMON (contd.) Applications

  • 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

Amon contd1
AMON (contd.) Applications

  • 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

Amon contd2
AMON (contd.) Applications

  • Activity measurement via accelerometer proved difficult due to placement on wrist.

    • Typing excited higher peaks than walking, although frequency analysis yields good results.

Amon contd3
AMON(contd.) Applications

  • Power analysis claims average current consumption of 25.4mA

  • For 1.25 AH LiION rechargeable battery, this yields just over two days of use.

Amon conclusions
AMON Conclusions Applications

  • 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.

Shoe integrated gait system sigs
Shoe-Integrated Gait System (SIGS) Applications

  • 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

SIGS Applications

Wireless pda based physiological monitoring system for patient transport
Wireless PDA-Based Physiological Monitoring System for Patient Transport

  • National Taiwan University

Pda contd
PDA (contd.) Patient Transport

  • 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

Pda contd1
PDA (contd.) Patient Transport

  • PDA program written in c++ has a real time display of vital signs

Pda contd2
PDA (contd.) Patient Transport

  • 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.

Mithril 2003
MIThril 2003 Patient Transport

  • 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.

Mithril 2003 contd
MIThril 2003 (contd.) Patient Transport

  • 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.

WearARM Patient Transport

  • 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.

Smartshirt Patient Transport

  • 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”

Patient centric network
Patient-Centric Network Patient Transport

  • MIT

  • Multi-tiered network architecture for monitoring patients.

Patient centric monitoring contd
Patient-Centric Monitoring (contd.) Patient Transport

  • 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.

University of alabama at huntsville
University of Alabama at Huntsville Patient Transport

  • 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.


Codeblue overview
CodeBlue – Overview Patient Transport

  • Harvard University

  • 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

Codeblue requirements
CodeBlue – Requirements Patient Transport

  • 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

Codeblue sensor pulse oximeter
CodeBlue – Sensor: Pulse Oximeter Patient Transport

  • 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

Codeblue sensor ekg
CodeBlue – Sensor: EKG Patient Transport

  • 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.

Codeblue sensor motion analysis
CodeBlue – Sensor: Motion analysis Patient Transport

  • 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

Codeblue pluto mote
CodeBlue – Pluto mote Patient Transport

  • 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

Codeblue s w architecture
CodeBlue – S/W Architecture Patient Transport

  • CodeBlue is implemented in TinyOS and provides protocols for integrating wireless medical sensors and end-user devices such as PDAs and laptops

Codeblue sensor interface
CodeBlue – Sensor Interface Patient Transport

  • 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

Codeblue localization motetrack
CodeBlue – Localization: MoteTrack Patient Transport

  • 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.

Codeblue routing
CodeBlue - Routing Patient Transport

  • 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

Codeblue routing cont
CodeBlue – Routing (cont.) Patient Transport

  • 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

Codeblue routing cont1
CodeBlue – Routing (cont.) Patient Transport

  • 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

Codeblue discovery protocol
CodeBlue – Discovery Protocol Patient Transport

  • 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)

Codeblue cbq
CodeBlue – CBQ Patient Transport

  • 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.

Codeblue gui
CodeBlue - GUI Patient Transport

  • Java-based GUI

    • Easy for medical personnel to use

    • Provides enough detail on patient status and location to identify trends

Codeblue results
CodeBlue - Results Patient Transport

  • 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

Codeblue results data rate
CodeBlue – Results (data rate) Patient Transport

  • 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.

Codeblue results 1 to 10 senders
CodeBlue – Results (1 to 10 senders) Patient Transport

  • 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

Codeblue results 3 receivers
CodeBlue – Results (3 receivers) Patient Transport

  • 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

Codeblue results fairness
CodeBlue – Results (fairness) Patient Transport

  • 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%

Codeblue results latency jitter
CodeBlue – Results (latency & jitter) Patient Transport

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)

Codeblue results mobility
CodeBlue – Results (mobility) Patient Transport

  • 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

Codeblue results multiple transmit
CodeBlue – Results (multiple transmit) Patient Transport

  • 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

Codeblue conclusions future work
CodeBlue – Conclusions & Future Work Patient Transport

  • Lack of reliable communication (although the problem can be mitigated through redundant transmissions)

  • Reliable routing is not required for all medical data

    • System should allow each query to specify its reliability needs in terms of acceptable loss, data rate, or jitter

  • Explore the impact of bandwidth limitations and effective techniques for sharing bandwidth across patient sensors

  • Address the lack of security

    • private-key encryption

    • public-key protocol for key distribution

Conclusions Patient Transport

  • We are still a long way from the Tri-corder, but sensor node and sensor network development have the potential to revolutionize patient care by allowing continuous, real-time, non-invasive, wireless monitoring of multiple patients.

  • Given the threat of MCEs (mass casualty events) sensor networks can greatly improve the ability of first responders to triage and treat multiple patients equipped with wearable wireless monitors.

It is not difficult to foresee the commercial health industry realizing the benefits from advances in sensor node and sensor network technology.

Items such as the Sport Kit ( allow Nike+ shoes to talk to the iPod. The sensor uses an accelerometer to measure activity, then wirelessly transfers this data to the iPod.