biotelemetry and body sensors: enabling ecg · pdf filebiotelemetry and body sensors: enabling...

Biotelemetry and Body Sensors:Enabling ECG Monitoring

A Thesis

Presented to

the Faculty of the School of Engineering and Applied Science

University of Virginia

In Partial Fulfillment

of the Requirements for the Degree

Master of Science

Computer Science

by

Andrew D. Jurik

May 2009

Approvals

This thesis is submitted in partial fulfillment of the requirements for the degree of

Master of Science

Computer Science

/Andrew D. Jurik/

Andrew D. Jurik

This thesis has been read and approved by the Examining Committee:

/Alfred C. Weaver/

Alfred C. Weaver (Advisor)

/John A. Stankovic/

John A. Stankovic

/Marty A. Humphrey/

Marty A. Humphrey (Chair)

Accepted by the School of Engineering and Applied Science:

/James H. Aylor/

James H. Aylor (Dean)

May 2009

Abstract

As the population ages and the risk of chronic disease increases, the cost of healthcare will rise.

Technology for mobile telemetry could reduce cost and improve the efficiency of treatment. In

order to achieve these goals, we first need to overcome several technical challenges, including suf-

ficient system lifetime, high signal fidelity, and adequate security. In this thesis we present the

design, implementation, and evaluation of a Mobile Biotelemetric System (MBS) that addresses

these remote medical monitoring challenges. MBS comprises a custom low-power sensor node

that accurately collects and analyzes electrocardiogram (ECG) data, a client service with a multi-

faceted policy engine that evaluates the data, and a web portal interface for visualizing ECG data

streams. MBS differs from other remote monitoring systems primarily in the policy engine’s ability

to provide flexible, robust, and precise system communication end-to-end and to enable tradeoffs

in metrics such as power and transmission frequency.

We show that, given a representative set of ECG signals, policies can be set to make the oper-

ation of the hardware and software resilient against transient ECG conditions for both security and

monitoring purposes. We demonstrate that our system adaptively trades off system-level metrics

based on a combination of operating conditions and user input, and that our heartbeat detection

algorithm performs well for challenging ECG input. Further, we incorporate security mechanisms

to safeguard our data and foil common attacks.

iii

Contents

1 Introduction 1

1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Problem Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Thesis statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4 Goals and Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.5 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.6 Thesis Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Related Work 8

2.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 Remote Medical Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3 Wearable Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4 System Dependability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.5 Heartbeat Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 System Architecture 18

3.1 Sensor Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2 MBS Client Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3 External Network and Web Portal . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.4 Sensor Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.5 Policy Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

iv

Contents v

3.6 Sources of Noise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4 Experimental Setup and Results 29

4.1 Power and Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.2 QRS Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.3 Policy Robustness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.4 Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5 Conclusions and Future Work 40

5.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.2 Present and Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Bibliography 48

Chapter 1

Introduction

There is an abundance of information in our everyday environment that goes unnoticed or unused

because it is unimportant or inaccessible. Humans naturally possess an array of senses—visual,

auditory, gustatory, olfactory, and haptic—that allows us to interact richly with our surroundings.

While those senses form the foundation of our interaction with the world, technology can sense,

amplify, and enhance other signals within and around the body. Some of that information, once

acquired, may provide valuable insights into our environs and ourselves.

Medical monitoring technology can produce such insights by instrumenting the body and en-

abling the exportation of a variety of physiological signals, either directly to a base station or

through a network of computational nodes. An effective monitoring system would alert concerned

entities when something may be amiss. For example, the system could initiate intervention when

certain physiological values are out of bounds. The presence of wearable, passive, and networked

“guardian angels” [1] has great potential to influence human behavior and improve healthcare.

1.1 Background

Chronic illness, particularly heart disease, is a problem that has a dramatic impact on the productiv-

ity of affected individuals and the cost of healthcare. Chronic illnesses account for over $1 trillion

in healthcare costs [2] and up to 70% of the deaths [3] in the United States each year. Insofar as

the risk of chronic illness increases with age and the average life expectancy of the U.S. population

1

Chapter 1. Introduction 2

continues to increase, the rising cost of healthcare will not subside. The prevention and effective

management of chronic diseases may be the only lasting solution, and remote medical monitoring

will be an integral part of that approach.

The emergence of small, energy-efficient, wireless sensors has enabled new data streams that

were previously unavailable. There are many types of sensors and often they are described in

the context of their deployment domains. Environmental sensors, for example, can discern light,

sound, temperature, and pressure among other parameters. Body sensors can sense temperature,

respiration, posture, electrocardiogram waveforms, and certain vital signs. Each type of sensor has

its own design requirements dictated by functionality, environment, dependability, etc. We focus

on the challenges presented by body sensors.

The ability to view and interpret physiological signals from a distance opens new opportuni-

ties and challenges. Health informatics, “the acquisition, management, and use of information in

health” [4], is a problem with many aspects. The essential components of a health informatics

system are those that collect data, synthesize raw data into information, and communicate that

information to humans who may synthesize it further into knowledge. A doctor may check on a pa-

tient periodically from the convenience of her office. Loved ones may assure themselves that older

family members are staying active (and independent). Military personnel may verify that their sol-

diers are in good health. Emergency responders in disaster scenarios may request more information

about the current situation before deciding on an approach to take. These examples represent only

a portion of the scenarios in which health informatics can stimulate beneficial applications.

1.2 Problem Overview

In order to address the challenge of chronic illness, it is natural to leverage technology. With

personal information becoming more available and the process of obtaining it becoming more au-

tomated, we must find how best to leverage the usefulness of physiological information while pro-

tecting it at the same time. Additionally we must address the technical questions of remote medical

monitoring, including lifetime, signal quality, and security. In this section we discuss an outline of


the problem space and basic requirements.

In any system involving body sensors, physiological signals need to be converted into a digi-

tal representation, typically with an analog-to-digital converter. There is an important distinction

between the ground truth phenomenon being sensed and the data that result from the sensor mea-

suring that phenomenon. Although the two are conventionally considered to be equivalent, this may

not be the case, especially in the event of a node failure. Two kinds of body sensors, implantable

and wearable, must contend with data-gathering challenges. Implantable sensors can provide data

not currently available to external sensors, but must be biocompatible and have a long lifetime.

Wearable sensors, on the other hand, are noninvasive and more accessible than their implantable

counterparts. Usability and noise management take on greater prominence as external sensors are

more likely to be affected by motion artifacts and the normal wear and tear of daily activity.

Once the data is sensed, it must be exported to a computational resource that can do further

processing. The base station, also called a data sink, may be another sensor, mobile device, or

router, and must be within sufficient range of the source sensor to communicate either directly or

via multihop routing protocols through other sensors. The application layer communication proto-

col can remain relatively unchanged over many different underlying network layer protocols. The

consumer market has many Bluetooth applications whereas many wireless sensor network applica-

tions adopt the IEEE 802.15.4 standard (including Zigbee) [5,6]. Tradeoffs in power consumption,

range, and services are present in the choice of protocol. We discuss the implications of this design

tradeoff in Chapter 4.

After the base station collects the data, the utility of the data increases with the ability to forward

it over an external network. While the processing capabilities of a mobile device such as a PDA

or cell phone are greater than those of the sensor nodes, they are not nearly as powerful as typical

laptops or desktops. We treat the mobile device as a gateway, either as a visualization tool for

a human to see the data or as a router to send the data onward to a back-end server. A remote

viewing portal can display the relevant information for as many people and sensors as are authorized

to access it. Latency, flexibility, scalability, and accuracy are all issues that the web portal must

confront.


Although a unidirectional framework answers the monitoring challenge, it leaves several prob-

lems still unresolved. For example, the ability to control the sensor to optimize power and data

volume tradeoffs provides flexibility to extend system lifetime and to specialize operation for par-

ticular scenarios such as an emergency. A bidirectional framework enables the sensor to be an active

participant rather than a passive bystander. Cyber-physical systems of the future will dictate that

sensors be able to affect their environment through actuation or user intervention. The problems on

which we concentrate involve how and under what conditions the seamless exchange of data will

occur. We study how to obtain ECG data and analyze its features. We probe the effect of sampling

rate on the accuracy of our heartbeat detection algorithm. Given that ECGs are highly variable, and

because sensors provide only limited resources, it is essential to understand the signal processing

requirements and capabilities for our application and their impact on the design space.

Another problem we address is how to guard mobile device data after a user session has been

authenticated, and how streaming physiological data and a policy engine may assist to that end.

Security is a pertinent issue in several domains, including healthcare facilities, businesses, and the

military. The risk of revealing sensitive information often demands data protection but usually at

the cost of data usability. While conventional solutions such as encrypting data or setting up access

control mechanisms are effective, once the data is decrypted or accessed the data become suscepti-

ble to an attack. Ad-hoc file encryption can be cumbersome; it is easy to circumvent or the user may

simply forget to enable it. Sophisticated access control for a single-user mobile device is generally

not an issue for personal mobile devices, but access should not be extended to unauthorized viewers

in security-critical situations. Periodic, explicit re-authentication based on user activity (or inac-

tivity) is unnecessarily obtrusive; an acceptable long-term solution must involve minimal explicit

human intervention. We investigate a method in which mobile devices can protect information after

a session has been authenticated via policies.


1.3 Thesis statement

Our Mobile Biotelemetric System is capable of providing an end-to-end “control

plane” in which data is exchanged bidirectionally by means of an adaptive policy

engine. The sensor accurately detects heartbeats and the mobile device enforces

policies, based on properties of the sensor connection and the sensor information,

to promote efficient cross-system tradeoffs.

1.4 Goals and Approach

In this work we have collaborated with researchers in the Electrical and Computer Engineering de-

partment at the University of Virginia in order to construct a prototype ECG monitoring system we

call MBS (Mobile Biotelemetric System). Once the ECG data is sampled and processed, it is then

transmitted to, and further analyzed on, a mobile device. The results of the analysis are adaptable

to particular scenarios, including simply providing feedback to the mobile device user of current

health status and protecting data files on a mobile device. Furthermore these analyses and goals

may be accomplished with different subsets of the system components. For example, the interface

to the external network may be unnecessary for athletic training or consumer entertainment.

Our goal for this thesis is to demonstrate the utility of a centralized policy engine in responding

to user requests for more (or less) information, thus influencing the flow of information from the

sensor through the mobile device to the web portal. Our approach is to analyze and justify our

choices for design goals and architecture in the context of the accurate and secure assessment of

ECG data. We have designed a custom printed circuit board with discrete components for sensing

a one-lead ECG signal with three electrodes. In present work we are developing an ultra low power

system-on-chip with a small form factor to prolong battery life and to provide sufficient signal

processing to detect heart rate accurately. We have refined an algorithm for detecting heart rate

both in the sensor node and in the mobile client. We have developed a user-level application with

several generic interfaces (sensor type, radio frequency (RF) medium, processing algorithm, etc.)

for receiving a signal and applying policies to control the state of the mobile device. In order to test


the system, we have devised a simulator that models the sensor, including transmission frequency,

mode of operation, and RF medium. We have implemented a method for varying data volume to

regulate sensor power based on remote user commands. Finally, we have constructed an encrypted

web-services interface for the mobile device to permit communication with an external or back-end

network.

The technical capabilities of the system must support the ultimate purpose of the system—in

this case, remote medical monitoring. Several factors play a role in specifying the functionality and

constraints of our system. Here we list the system design points.

• Wearability and usability. In order for a system to be successful users must be

willing and able to use it. Therefore, the sensor must conform to a reasonable

form factor and require as little user intervention as possible to use it.

• Long lifetime. The sensor and mobile device must conserve energy to extend

the life of the battery for as long as possible. Reducing communication costs and

active computation serve to meet this objective.

• Accuracy. The signal processing on board the sensor must be accurate and re-

silient to many types of signals. No body sensor will be able to sense the ‘perfect’

waveform because of changes in the electrode-skin interface, motion artifacts,

and quantization errors, for example. Real-world difficulties inherent in sensing

data must be overcome to reduce false positives and false negatives.

• Near real-time. Sufficient performance dictates that the sensor data are pro-

cessed and propagated through the system with reasonable delays (which will be

inevitable due to the routing of the sensor data from the sensor through a mobile

device to the Internet).

• Conformity to security best practices. A design that treats security as an af-

terthought or ignores it altogether is inappropriate in today’s society. Basic en-

cryption, authentication, and authorization protocols should be utilized through-

out the system.


There are several aspects of the system that we do not claim to address in this thesis. MBS is

not intended to make clinical decisions—rather, the information gleaned from the system is meant

as guidance and as an aid. We do not propose a novel authentication or authorization mechanism—

rather, we adopt state-of-the-art mechanisms. We do not make any assertions regarding the system’s

end-to-end security, other than we use commercial best-practice techniques, such as encryption, that

reinforce aspects of security. Finally, we assume that the base station is online at all times to prevent

the need for store-and-forward operation on the sensors, which have limited memory.

1.5 Contributions

This thesis presents a novel methodology for providing efficient system-level tradeoffs based on the

use of physiological information as an input to a policy engine. Our main contributions lie in the

emergent properties of the integration of diverse components for monitoring. We have devised a

policy engine for monitoring events based on sensor connections and sensor data. The output of

the policy engine, i.e., policy actions, performs some operation or alters the mobile device’s state to

achieve application-specific goals and favor particular tradeoffs along a spectrum (e.g., operational

mode). We have identified potential threats and have analyzed the technologies that MBS uses to

cope with them. The end-to-end system implementation and evaluation of MBS is a contribution

that spans the design space from within embedded software to the mobile device application and

further to the interaction between a database and web portal.

1.6 Thesis Organization

The remainder of this thesis is organized into four chapters. Chapter 2 presents a survey of the

relevant literature and work that this thesis extends. Chapter 3 outlines the end-to-end architecture

by describing the system components and their interfaces. Chapter 4 details the experiments used

to evaluate the architecture and explains the results, putting them into context. Chapter 5 provides

our conclusions and identifies areas in which future work will be required.

Chapter 2

Related Work

An abundance of work has been performed in the general fields of telemedicine, pervasive com-

puting, and computer security. In this chapter we discuss architectures and approaches similar to

our Mobile Biotelemetric System and divide them roughly into three categories. First we present

telemedicine systems with goals similar to ours. Second we specifically address wearable comput-

ing systems in which sensors are incorporated into the user’s environment like a prosthetic. Finally

we analyze approaches to dependability, including security, that systems employ based on biomet-

rics and human-centric data.

2.1 Motivation

In these uncertain times healthcare is facing a crisis. Several organizations have recognized the

urgency of improving the efficiency of healthcare transactions, including the Social Security and

Medicare Boards of Trustees and the Centers for Disease Control (CDC). In their 2008 Annual

Reports, the Social Security and Medicare Boards of Trustees noted that “Medicare’s financial

difficulties come sooner—and are much more severe—than those confronting Social Security” as

expenditures are expected to reach 10.8 percent of GDP in 2082 (as compared to 3.2 percent in

2007) [7]. A committee of the National Academy of Engineering cited advancing health informatics

as one of the fourteen grand challenges for engineering in the 21st century [4]. Automated data

capture and automatic decision support have been identified as two notable challenges in health

8

Chapter 2. Related Work 9

informatics [8]. The acquisition and management of health information serves the overarching goal

of (1) improving the quality of care to patients and (2) increasing the cost-effectiveness of providing

such care.

In summary, healthcare is an issue in which many problems arise, and we assert that technology

is a direction that can solve some of them. Political and sociological pressures will play a signifi-

cant role in solving the healthcare puzzle, but in the meantime, science and technology can make

significant inroads. In this chapter we differentiate our work within the realm of remote medical

monitoring.

2.2 Remote Medical Monitoring

Several remote medical monitoring architectures have been proposed and developed in both indus-

try and academia. Many implement a tiered architecture [9–13] in which sensors, base stations,

and computing devices in an external network are distinguished from each other and interconnected

through their (often wireless) connection interfaces.

2.2.1 Architectures in Academia

Many of the research projects in academia focus on only aspects of monitoring systems and do

not implement a full end-to-end system as MBS does. Pollard et al. [13] design a three-tiered

medical monitoring system but consider the three tiers the user interface, the web server, and a

“real-time server” that contains temporary storage and servlets. Our system emphasizes the distinc-

tion between the sensor and the mobile device as separate entities with separate, but interrelated,

responsibilities. Hung et al. [14] develop a telemedicine system based on the Wireless Application

Protocol (WAP), which allows for HTTP access via a mobile phone or PDA. The limitation of this

work is that the system is meant for viewing data on a phone and neglects the process of uploading

the data. In the evaluation, for example, data was manually entered into the database.

The CodeBlue architecture [5] provides multiple services and acts as an information plane

that promotes sensor intercommunication. CodeBlue’s primary application is emergency scenar-


ios whereas our system focuses more on day-to-day usage rather than triage. We do not adopt the

paradigm of deploying a set of sensors and allowing them to self-configure, but rather we focus

on using body sensors in a more controlled environment. Gao et al. [15] extend the CodeBlue ar-

chitecture by integrating it with a commercial software package on a tablet PC and developing a

web portal. Their various wearable sensors are capable of vital signs monitoring, location tracking,

medical record storage, and triage status tracking. The MobiHealth service platform [16] has a

stated goal of “bringing body area network technology together with wireless broadband communi-

cation and wearable medical devices to provide mobile healthcare services.” MobiHealth includes

the BAN interconnect protocol (BANip), which is based on Java, Remote Method Invocation, and

a 2.5/3G wireless infrastructure. BANip heavily utilizes the Jini service-oriented architecture for

making body area network services available.

Jea et al. [12] extend the three-tier architecture by adding a peer-to-peer component and devel-

oping the idea of “multi-resolution” to permit different granularities of data collection. The tech-

nical details of the implementation are exposed to the message interface, however, and so humans

analyzing the data must sift through potentially unnecessary metadata. Liszka et al. [17] present a

real-time remote arrhythmia monitoring system with GPS. They distinguish between the notions of

a noncritical alert (such as heart flutter) and a critical alert (requiring emergency assistance).

Rather than using a body sensor approach, “smart homes” hold the promise of monitoring

patients by embedding sensors in their homes. ALARM-NET [6], for example, is an extensible net-

work architecture for residential living that integrates context-aware protocols to enable customized

power management and alert policies. The Smart Medical Home [18] at the University of Rochester

is another example of a setting in which the interplay between humans, sensors, and displays is re-

searched. While we do not adopt a “smart home” approach, there are many parallels in the way

information is aggregated in a base station in a smart home and in a base station in our system.

2.2.2 Architectures in Industry

Companies have a large incentive to develop and market innovative medical solutions—as our pop-

ulation ages, the healthcare market expands. Federal regulatory authorities such as the Food and


Drug Administration (FDA) and the Federal Communications Commission (FCC) play a nontrivial

role in ensuring standards compliance and defining the scope of liability and legal issues.

Several corporations have taken on the challenge of creating a medical monitoring product.

CardioNet [19] offers a commercial cardiac monitoring service with automatic arrhythmia detec-

tion and wireless transmission of the ECG through the cell phone network. Medtronic [20] and

Biotronik [21] have also developed wireless remote monitoring solutions with implantable cardiac

devices such as ICDs and pacemakers. Personal Care Connect [11] is a platform for a set of het-

erogeneous biomedical devices to communicate with a data hub, which then communicates with a

server. It is an “open” system (ideally designed to interface with any number of proprietary sensors)

that uses a blackboard communication model where agents both subscribe to and publish events.

The events in PCC’s communication model have a straightforward mapping to events in our policy

model.

A plethora of heart rate monitoring systems have been introduced within the last several years.

Zephyr’s BioHarness, Equivital’s Sensor Electronics Module (SEM), Textronics’ NuMetrex heart

monitoring apparel, Toumaz’s Sensium, and VivoMetrics’ VivoResponder are all heart rate moni-

tors based on chest straps or textiles that sense the heart rate. Most are targeted to fitness training

applications and do not focus on obtaining a faithful representation of an ECG (if an ECG is avail-

able at all). The lack of contact electrodes on most of these systems raises questions about accuracy

of heartbeat detection and any other feature extraction.

2.3 Wearable Computing

Although several sensor systems have been implemented with Bluetooth as the wireless

medium [14, 16, 22, 23], our design provides a more extensive solution with a custom sensor and

web services compatibility. Some systems do not have a sophisticated base station, and some do

not forward data to a location at any location beyond the base station.

Several researchers have developed ECG monitoring devices, primarily for healthcare and

athletic-training reasons. Park et al. [22] present an ECG monitoring system with comparable


power consumption to MBS but do not discuss any signal processing or the implications of how

their system is meant to be used. Anliker et al. [24] create a wristwatch system, AMON, with mul-

tiple sensors, including an ECG sensor, that is meant to provide a multi-faceted sensor profile. They

acknowledge, however, that the ECG “provides poor or no results” due to the signal’s derivation

from the wrist where the signal-to-noise ratio is low. Lucani et al. [25] develop an ECG monitor-

ing device for telemedicine applications but with different design goals from MBS (for example,

in their system, power and form factor are not large concerns as two AA batteries are used on the

sensor). The authors additionally do not discuss the user interface of the system.

Lorincz et al. [5] establish a software framework, CodeBlue, that operates as an information

plane in a disaster scenario, allowing devices to discover each other and report events. The design

of MBS does not focus on triage situations, but rather on the utility of a particular mobile device

coupled with its sensor for long-term monitoring. Gyselinckx et al. [26] describe their Human++

research program for health monitoring applications in body area networks. They have developed a

flexible substrate with a bandage-sized form factor that has the potential to make the sensor lighter

and more comfortable to wear. Innovations in wearable computing and “smart” clothes [27–29]

have increased the usability and convenience of body sensors but usually do so at the cost of accu-

racy.

2.4 System Dependability

Our system’s successful operation hinges upon the dependability of the components, from the sen-

sors to the delivery of information via the web portal. In this section we develop the context through

which our system can be understood from a dependability perspective rather than from a purely

functional perspective.

2.4.1 Definitions

Avižienis et al. [30] precisely define the notions of terms relating to dependability and security in a

taxonomy of concepts and attributes. Often the term reliable is used to denote that a system does


what it is intended to do. Avižienis generalizes the notion of dependability as “the ability to avoid

service failures that are more frequent and more severe than is acceptable” [30]. The five attributes

of dependability are identified as:

• availability: readiness for correct service

• reliability: continuity of correct service

• safety: absence of catastrophic consequences on the user(s) and the environment

• integrity: absence of improper system alterations

• maintainability: ability to undergo modification and repairs

Security consists of confidentiality (the absence of unauthorized disclosure of information), in-

tegrity, and availability. Most of these attributes are relevant to our system as emergency scenarios

require availability with high probability and normal operation demands reliability with high prob-

ability. The security of MBS is addressed through various techniques such as encryption, access

control, and our policy engine.

2.4.2 Security

With a definition of security in place, we may now consider how systems have addressed security

in mobile ad-hoc networks and wireless sensor networks. The security of mobile devices and the

unique problems associated with pervasive computing have been well documented [31–33]. Attacks

such as radio jamming and sleep deprivation torture (i.e., keeping a device awake to drain its battery)

are legitimate problems, but MBS addresses them through the policy engine. Denial of service will

simply cause a disconnection or timeout event and sleep deprivation torture is difficult because once

the Bluetooth radio is connected, it does not respond to service inquiries. More subtle attacks based

on traffic analysis and surveillance are mitigated by the Bluetooth radio’s power and range (which

are limited to an immediate area around the radio).

While it is may be perceived that security is not a primary concern for implantable medical

devices [34], their increasing connectivity and storage capabilities make attacks a real and legitimate

threat. Availability, confidentiality, and integrity become much larger concerns in a networked


society. The Health Insurance Portability & Accountability Act (HIPAA) was passed by the United

States Congress in 1996 to reform healthcare laws in the electronic age. One of HIPAA’s goals

was to establish a baseline for privacy and security of medical data without prescribing particular

implementation methods [35]. It is unclear how the medical data on implantable medical devices

should be treated, as encryption and secure transmission of the data from a power-constrained

implanted device may be unrealistic or at the least detrimental to the device’s other priorities. The

field of body area networks is in its infancy as technology is emerging that is conducive to satisfying

such constraints. One can envision scenarios in which devices attached to the body (either internally

or externally) communicate with one another to monitor a patient’s overall state of health. For

example, in August 2006, the FDA sought public input on the idea of using RFID tags in implanted

devices such as pacemakers.

Anticipating these new security requirements, researchers at the University of Washington doc-

umented a set of requirements for security and privacy in implantable medical devices [36]. The

researchers also demonstrated that an attack on an actual pacemaker is not infeasible. After reverse-

engineering the ICD’s communications protocol with an oscilloscope and a software radio, the at-

tacks could compromise patient safety and privacy. For example, often defibrillators have testing

modes that induce ventricular fibrillation to verify that the automatic defibrillation mechanisms acti-

vate. While the external programmer’s interface makes it difficult to induce a shock when therapies

are disabled, an adversary who bypasses the programmer can circumvent those safeguards [37].

Such attacks and evidence that they have been mitigated should be part of a thorough examination

of system safety.

A programming languages technique to address security, information flow [38], seeks to define

limits on information dissemination by distinguishing between acceptable and unacceptable flows

of information. Confidentiality policy specifications are integrated into software (e.g., through type

systems) and serve to describe flows of data between variables and their associated principals.

Satisfying the specification provides an end-to-end security guarantee provided that the underlying

machinery of the compiler is correct. Guaranteeing confidentiality in a distributed environment

(such as MBS) poses a more difficult problem to which solutions are still being researched and may


be applicable in the future.

2.4.3 Authentication and Biometrics

The use of the ECG as an offline (i.e., post-data-collection) identification mechanism based on

feature extraction has recently been studied. Signals from electrodes placed close to the heart are

subject to waveform changes when the electrodes are displaced by even as little as 10 mm [39].

Wübbeler et al. [40] found that a three Einthoven (limb) lead system achieved an equal error rate

of 2.8% for verification and an accuracy of 98.1% for identification. Biel et al. [41] and Israel

et al. [42] use the standard 12-lead ECG to characterize the signals and identify individuals post-

collection (i.e., not in real time). MBS’s goal is not identification of an individual (authentication is

done through other means), but rather to verify the individual’s proximity.

Several researchers have investigated the use of biometrics not only to authenticate individuals

but also to secure systems. Kumar et al. [43] have researched the use of biometrics in securing shell

login sessions and Poon et al. [44] developed a means to secure body area sensor networks based

on R-R (also called interbeat or peak-to-peak) intervals. Neither has demonstrated the feasibility of

the techniques in practice, as the former requires a resource-rich Linux workstation with continuous

fingerprint and face detection technology and the latter adopts R-R intervals as a biometric, which

are not unique and depend largely on transient factors such as activity level.

2.5 Heartbeat Detection

In order to describe heartbeat detection, it is first relevant to describe the natural processes that take

place in order to produce heartbeats. The heart’s primary natural pacemaker, the sino-atrial (SA)

node, regulates an individual’s heart rate. The SA node interacts with the nervous system to dictate

the rate at which it fires in order to appropriately react to the environment. When the SA node

initiates a heartbeat, the electrical flow is from the atria down to the ventricles. The right atrium

receives blood from the body and delivers it to the right ventricle, which sends the deoxygenated

blood to the lungs to be oxygenated. The left atrium receives the blood from the lungs and then


P

Q

R

S

T

R-R Interval

QRS Complex

(a)

Sinoatrial

(SA) Node

(b)

Figure 2.1: A typical ECG (a) contains five common deflections whose distances between oneanother can vary in time and intensity based on many factors, including physiology and activitylevel. The deflections arise as a result of cardiac conduction (b), with the atrioventricular bundle(muscle cells specialized for electrical conduction) superimposed.

sends it to the left ventricle. With a strong contraction the left ventricle pumps the blood to the rest

of the body.

The stages of the blood flow through the heart (and the associated electrical activity) are rep-

resented in the features of the ECG signal. The five primary points in the ECG are alphabetically

labeled P, Q, R, S, and T as shown in Figure 2.1 along with a diagram of the heart. The prominent

QRS complex represents ventricular depolarization while the introductory P wave represents atrial

depolarization. The T wave following the QRS complex depicts the repolarization of the ventricles,

and the subsequent period of inactivity reflects the heart’s resting state [39].

The detection of heartbeats, also referred to as QRS complexes based on the names of the de-

flections in the ECG, has been an active research topic for several decades. Pan and Tompkins [45]

developed the archetypal QRS detection algorithm in 1985 on which we base our implementation.

In the algorithm, the sampled ECG signal first passes through a digital bandpass filter. The signal is

then differentiated and squared to enhance the deflections in the QRS complex. Finally, a moving


window integrator produces a “clump” of a certain height when a QRS complex has been detected.

Hamilton et al. [46] refined the basic algorithm and analyzed the effect of each component upon

detection accuracy. After a rigorous evaluation of their heuristics, they concluded that iterative peak

estimation is the most important decision rule component (followed by the mean and median peak

estimates and the detection threshold with noise estimate).

Friesen et al. [47] present a systematic comparison of the noise sensitivity for nine QRS detec-

tion algorithms. The algorithms were partitioned into four groups based on approach (amplitude

and first derivative, first derivative only, first and second derivatives, and digital filters) and pure

signals were artificially corrupted with noise. They concluded that no one algorithm is superior in

all cases, but the limitation of the study is that each algorithm was treated in isolation (e.g., the 60

Hz digital notch filter could be applied to any of the algorithms in a preprocessing stage but was

only done for a digital filter algorithm). Meyer et al. [48] combine the Pan-Tompkins algorithm and

a wavelet algorithm based on configurable parameters that can outperform either algorithm operat-

ing alone. Unfortunately the complexity of the algorithm (particularly the wavelet) is not generally

applicable in a resource-constrained embedded device with current technology.

2.6 Summary

Although we have listed several systems that have been created that monitor ECG signals or possess

a similar architecture, none combines the openness and flexibility of a user-directed, policy-driven

engine that addresses system operation in a holistic way. Much of the related work stops short of

considering cross-hierarchy design issues due to their limited scope. The signal processing compo-

nent of the work, the networked nature of the system components, and the roles that hardware and

security play in our system require an examination of a large cross section of technical literature.

In this chapter we have presented the most notable results.

Chapter 3

System Architecture

MBS adopts a classical three-tier architecture in which the sensors, mobile devices, and the outly-

ing network cooperate to adjust the flow of information throughout the system. Figure 3.1 diagrams

the major architecture components and flow of information between them and Figure 3.2 pictures

the working implementation. Tier one consists of a physiological sensor (initially an electrocar-

diograph), microcontroller, and radio (initially Bluetooth) with the form factor of a bandage. The

sensor prototype collects and processes ECG data and transmits the processed information over

the wireless channel either continuously or periodically. Tier two is the mobile device (e.g., PDA

or laptop), which supports a number of programmable policies through the policy engine that can

map events to actions. Tier three is a web portal that, together with associated web services and

a database, allows authorized users to view the sensor information remotely either in real-time or

post-collection.

Our system has three guiding design goals. The first goal is flexibility with respect to sensor

operation. We respond to this goal through the policy engine’s ability to map events to actions

and through bidirectional communication. The second goal is low power consumption. This goal

coincides with the requirement that the system, including the body sensor, should be long-lived.

The third design goal is usability. The usability of MBS, and of wearable computers in general, is

difficult to quantify but critical to technology acceptance. In the case of MBS, the placement of the

electrodes takes a few minutes and the connection setup takes approximately one minute. In this

18

Chapter 3. System Architecture 19

Front End

CPU Core

Signal Quality

Control

Digital Sample

UART

Processed Signal

Bluetooth

ECG Signal

Data

Stream

Event Policy

Engine

Action Policy

Engine

Web Service:

Push to database

Web Service:

Pull from database

XML

Web Portal /

User Interface

Feedback

Signal Transmission

Sensor

Database

ADC

Chart

generation

Sensor

Mobile

Device

External

Network

Figure 3.1: The sensor produces data that flow to the mobile device and external network whilecontrol commands flow back to the sensor.

section we further describe our approach and an overview of the system.

3.1 Sensor Design

The design space for the conversion system (front end) from physical heartbeat to digital signal

must consider at least six different factors: accuracy, sampling rate, gain, processing speed, power

consumption, and form factor (size) [39]. Depending on the information that is desired from the

ECG, different acquisition methods are used that are distinguished by such factors as data resolution

and maximum recording time. The standard 12-lead ECG consists of three standard limb leads (I,

II, and III), three augmented limb leads (aVR, aVL, and aVF), and six precordial (chest) leads (V1

through V6). The limb leads are derived from four electrodes on the right arm, left arm, left leg,

and right leg. Each lead represents a signal, which is on the order of 1 mV, and may be derived from

multiple electrodes. The precordial and augmented limb leads are unipolar (the lead is formed with

respect to a neutral center electrode at zero potential) whereas the standard limb leads are bipolar,


Figure 3.2: The sensor sends a wireless signal to the mobile device.

as each electrode is at a nonzero potential.

While providing a thorough view of the heart, the standardized placement of electrodes in a

12-lead ECG is often inconvenient and more than what is required for many applications. Holter

monitors are common, portable devices that can record ECGs for 24 hours or more. They often

use between three and eight electrodes. There have been numerous studies on which leads are best

for studying particular conditions [39]. In MBS we use one lead to derive an ECG signal and the

associated R-R (also called interbeat or peak-to-peak) intervals for the purpose of input to the policy

engine.

Our sensor prototype with discrete components has the form factor of a bandage and is attached

to the user (patient) via three disposable electrodes that connect to the sensor via snaps. Two of

the electrodes are used to make a differential measurement of the cardiac signal, and a third is used

to hold the user at a fixed potential relative to the prototype ground. This provides a large input

impedance and high common-mode rejection, which reduces many forms of interference. The

electrodes can be placed on the chest, ideally in positions similar to the standard precordial leads.

A two-stage amplifier topology was chosen, the first stage consisting of an AD623 instrumen-

tation amplifier with adjustable DC offset, and the second stage consisting of a single-ended ampli-


fier with adjustable gain. A Texas Instruments MSP430 microcontroller with an integrated 12-bit

analog-to-digital converter (ADC) is used to digitize the signal. Feedback from the MSP430 is

used to adjust the DC offset and gain, so that the cardiac signal occupies the maximum dynamic

range of the ADC. The prototype is powered from a 430-mAh polymer lithium-ion battery, which

is regulated with an LTC4080 integrated charger and DC-DC buck converter.

3.2 MBS Client Service

We organize the MBS client service on the mobile device into three main operational blocks: the

wireless radio, the policy engine, and the external network interface. We assume that the mobile

device is normally powered up and able to receive data from the sensor, which is generally a fair

assumption for mobile devices with small form factors. The MBS client service can operate in the

foreground (with a user interface displaying pertinent information) or in the background.

The wireless radio interface exports a stream of data such that the rest of the client service does

not need to account for the details of the wireless radio used. We implement the client service to

accommodate Bluetooth radios and the TCP/IP suite of protocols commonly associated with the

IEEE 802.11 standard. Certain events may stem from the properties of the radio, including whether

the radio is connected and whether the radio has received data within a specified amount of time.

The policy engine incorporates these properties as events.

The policy engine is discussed at length in Section 3.5, but it is important to note here that the

policy engine’s placement on the mobile device is a key aspect of the hierarchical framework. The

mobile device has more computational resources than the sensor and is in proximity to the user so

decisions can be incorporated quickly into the policy engine. The centralized location of the policy

engine simplifies the architecture by facilitating mediation between the tiers.

The external network interface in the client service allows data to be exported as either an

ECG signal or a heart rate signal. In order to prevent re-implementation of a heartbeat detection

algorithm at the web portal and to leverage computation that has already occurred, the client service

automatically piggybacks the heart rate value onto the ECG signal when unicasting data. The ECG


signal is sent in 2048-byte blocks to reduce the number of transmissions over the wireless channel.

We address the security of the wireless channels between the MBS client and the other tiers by

enabling encryption and authentication, preventing unauthenticated users from gaining access to

the service.

3.3 External Network and Web Portal

The external network and web portal expand the set of concerned entities beyond a single user;

remote monitoring organizations can also participate. The communication between the MBS client

and an external database is structured around a service-oriented architecture. We created two prin-

cipal web services. The first pushes the data from the mobile device to a remote MySQL database

and the second pulls the data from the database to the web portal. While we do not claim that our

web portal is “secure,” we take significant measures by adopting security best practices (e.g., re-

quiring SSL, authenticating and authorizing web portal accounts, validating user input, encrypting

the database connection string in a web.config file, using a limited-access database account to

access and update the data, etc.).

The heart rate, ECG signals, and any actions of the policy engine (via messages) are the pri-

mary sources of information for the web services. Heart rate can be determined regardless of the

particular mode of operation that the mobile device has requested and therefore is always able to be

derived. The actions of the policy engine, while directly impacting the operation of the mobile de-

vice, also serve to inform a remote monitoring center by highlighting alarms or events of particular

interest.

The MySQL database has a relatively simple schema, as shown in Figure 3.3, and provides

the minimal functionality for our application. The users table contains the users of the system,

the connections table contains information about when and who connected to the database, and

finally the sensordata table holds sensor readings. In the case of ECG signals, the data is stored in

2076-byte blocks (as a result of how it is transmitted from the mobile device). A separate database

manages the web portal authentication and authorization via the ASP.NET web site administration


sensordata

rowid INT UNSIGNED

Data_Timestamp DATETIME

Data_Values INT

Sensor_Type VARCHAR (45)

Connection_ID INT UNSIGNED

Data_Blob BLOB

users

User_ID INT UNSIGNED

Username TEXT (65535)

connections

User_ID INT UNSIGNED

Connection_Time DATETIME

Connection_ID INT UNSIGNED

Figure 3.3: The database has three tables to store user data, connection data, and sensor data.

tool and the MySQL Connector/Net driver.

The web portal is hosted by a Microsoft IIS web server and its interface, shown in Figure 3.4,

is guided by the visual information seeking mantra, “overview first, zoom and filter, then details-

on-demand” [49]. The heart rate of multiple users can be displayed at one time, providing the

overview. A user’s name can then be clicked to obtain more information. In order to view ECG

data dynamically we leverage the Highslide JS library for point-and-click ease of viewing the ECG

and the XML/SWF Charts library to produce dynamic chart content.

Viewing data in real-time for at least ten users is an important feature of the system, but it also

complicates the viewing of archival data for specific users. To reconcile this we developed another

user interface that allows more fine-grained control of metadata specification. For example, the

user, type of signal, connection time, and a signal window length may be provided for the web

portal to render a chart.

Originally our implementation of the web portal’s sensor stream visualization was stateful in

that the web server retained information for each connection and each sensor stream. As the number

of connections and number of users scaled, however, the complexity of managing the information

became overbearing. As a result we transitioned to stateless web services and made several opti-

mizations. For example, since the chart is defined by an XML document we embed the specification

for the chart in client-side code and return only the data portion of the chart from the server.


Figure 3.4: The user interface permits an overview of heart rates and a view of the full ECG signalon demand.

3.4 Sensor Simulator

The sensor simulator provides a testbed for ideas and protocols that may be placed in the discrete

prototype. The simulator handles multiple, distinct connections via both TCP/IP and Bluetooth

and two signal file formats (i.e., Format 8 and Format 160 associated with the WFDB software

package [50]). For testing and evaluation, signal files of pre-recorded data are loaded and a heart

rate signal is controlled interactively.

The simulator adopts a server role as it communicates with the MBS client service. We ac-

knowledge here that the simulator could be used as an attack tool for replaying ECG signals, but

this can be guarded against through authentication at the link layer. If the simulator is deployed via

an untrusted Bluetooth radio, the client service will not connect to it.


3.5 Policy Engine

The policy engine functions as the core of the functionality mechanism on the mobile device. It

enhances the robustness of the system against pervasive problems such as noise, radio irregularity,

unstable electrode contacts, and motion artifacts. The policies represent a mapping from events, E,

to actions, A. The policies are separated into two subsets: those based on the quality of the signal

and those that pertain to the nature of the physiological data received. For example, the set of events

in our implementation are {Disconnection, Signal timeout, Low heart rate, Sensor removed, Low

battery on sensor} and the set of actions include {Change Mobile Device State, Send Message to

Portal, Send Message to Sensor, Ignore}.

These events and actions are not comprehensive, and a single event can be mapped to multiple

actions. While in our implementation we do not specifically focus on sensors other than ECG

sensors, we can foresee the idea of policy-driven operation to other body sensors. Accelerometers,

for example, could trigger a policy action when acceleration along a particular axis, modulo noise,

exceeds some threshold. A blood glucose meter may enact a policy action when connected or

disconnected. Sensors in general share many overlapping characteristics that could be used as input

to a policy engine regardless of the particular sensor instance invoked.

Policies are defined in a variety of ways. The graphical user interface provides a hook into

the policy engine such that policies may be modified at run-time with an administrator account,

otherwise policies are configured per user such that they get compiled into the object file statically.

This strategy allows sufficient flexibility without dealing with the risk of lost or modified external

policy files that would be read in while the program is running.

In terms of implementation, each policy is inherited from an abstract policy class, which con-

tains fields for the user interface form, an enabled flag, and a mobile device state. Upon receipt of

data, the policy engine passes control through several modules, including data logging, unicast to

web site, signal processing, and chart display. A factory method makes the events, and a subroutine

processes the events to determine if an action is warranted (that is, if a callback has not already

precipitated an asynchronous action). For example, the Signal Timeout event relies on a timer with


a callback that performs an action if time expires. Adding or modifying a policy requires a new

inherited class with associated implementations of inherited methods, a modification to the user

interface, the factory method, and the centralized processing subroutine.

3.5.1 Operational Modes

One key crosscutting concern is the management of resources across the system to minimize latency

and power consumption while maximizing signal fidelity. In emergency scenarios, sacrificing sys-

tem resources in favor of saturating bandwidth and providing full signal information is a reasonable

tradeoff. Although it may be possible for the sensor to infer such scenarios, flexibility is gained and

false positives are reduced by allowing the user to override the flow of information dynamically.

In our ECG setting, both the sensor and the MBS client service operate in one of two distinct

modes: heartbeat or waveform mode. They operate in tandem, such that messages are exchanged

when transitioning between modes. The heartbeat mode, which transmits the preceding peak-to-

peak time when a QRS complex is detected, has a higher computation cost but a lower communica-

tion cost. The waveform mode, however, sends the sampled waveform directly to the mobile device

without any substantive processing. This mode reduces computation, but increases the required

amount of communication.

3.5.2 Policy Events

Policy events intend to capture situations that could affect the interpretation of the sensor data. The

Disconnection event occurs when the connection is forcibly closed, which may be caused by the

sensor being turned off or the mobile device going out of range of the sensor radio. The Signal

timeout event occurs when a connection is still established, but a data packet has not been sent

within a configurable timeout period. This umbrella event is used to guard against failure of the

radio (or any component on the sensor before the data gets sent from the microcontroller to the

radio).

The Low heart rate and Sensor removed events are detected based on the contents of the data

packets. The Low heart rate event, in particular, is derived directly from the QRS complex detection


algorithm. Within the source code, the Low heart rate event is parameterized by a window of R-R

intervals such that transient results and long-term trends may be traded off. We analyze the effects

of this window in Chapter 4. For example, if the QRS detector misses a beat or the Bluetooth

connection is weak, a larger window may obfuscate the effect. This approach has the disadvantage

that the policy engine is less responsive. The Sensor removed event is detected when the signal

flatlines high or low for a period of time as a result of noise. The Low battery on sensor event is

detected when the voltage monitor in the processor detects a voltage below 2.65 V, a 12% drop

from the normal supply voltage of 3.0 V. While more events can be recognized, we restricted them

to this subset as they have proved the most useful in practice. The design of the software is such that

instances of events inherit from an abstract base class and a centralized routine polls event functions

each time a sample is received. Alternatively, events may have callback functions that occur based

on timers.

The events are periodically monitored based on their occurrence rate. For example, Signal

timeout has a running timer that gets reset every time data is received. The Disconnect event is

incorporated into (and dependent upon) the wireless protocol. The Low heart rate event and Sensor

removed event analysis is triggered every time the signal is delivered to the MBS service. The Low

battery event is communicated in the form of a message sent from the sensor (which has a voltage

detector on-chip).

3.5.3 Policy Actions

Policy actions explicitly permit application-specific goals to be achieved. Changing the device

state and sending messages to other tiers of the system are two examples of useful policy actions,

for example. These two actions working in concert enable bidirectional communication and allow

remote control of sensor-level metrics and different data to appear on the mobile device’s and web

portal’s user interfaces.

Changing the mobile device’s state may be as simple as displaying a notification to the user of

a particular event or as complex as locking out the mobile device. In a military application, for

example, if the presence of ECG data is used to verify proximity to a mobile device and suddenly


data is no longer being received, an appropriate action may be to lock the mobile device pending

reauthentication. The ability to change events, actions, and the mapping between events and actions

makes our system flexible. The policy engine can be the invariant link between many types of

applications.

3.6 Sources of Noise

Compensating for the inconsistencies in the ECG signal presents perhaps the greatest single chal-

lenge to interpreting the MBS policies correctly. Sources of noise are encountered at every stage

of data acquisition until the data is digitized. Power line (60-Hz) interference, muscular contrac-

tions, electrode movement, and analog-to-digital converter noise all perturb the ECG signal. The

variability in the conditions of the wireless channel is another source of unpredictable noise. If an

electrode is removed (intentionally or unintentionally) the ECG signal becomes indecipherable.

We approach this problem through several different tactics. First, including an additional ref-

erence electrode significantly attenuates power line noise. Second, the QRS detection algorithm

uses cascaded low-pass and high-pass filters to preserve the frequency content of the ECG while

reducing noise. Third, when an electrode is removed, the signal flatlines high or low (depending

on which electrode) and when the policy engine encounters this situation, it can perform the action

that the policy engine specifies.

3.7 Summary

In this chapter we have presented the components of our end-to-end system implementation of

MBS and their interfaces. We have analyzed the design space and outlined the goals of the em-

bedded software, mobile device software, and web portal and accompanying services. We have

described our custom ECG sensor and how we combine operational modes with signal processing

to enable policies. We have explained how policies can adaptively control the state of the mobile

device through the interaction of events and actions. In the next chapter we discuss how our system

responds to microbenchmarks that test our hypothesis in light of our goals.

Chapter 4

Experimental Setup and Results

In this chapter we evaluate MBS in terms of power, performance, accuracy of QRS detection, and

policy robustness. We chose these metrics because they provide a holistic view of the effectiveness

of MBS in general and the policy engine in particular. We provide a breakdown of the power in the

body sensor and the performance of the MBS client service and web portal. We analyze our R-R

interval detection algorithm in terms of false positives and false negatives. Lastly we look at the

robustness of policy detection and an analysis of threats to the system.

4.1 Power and Performance

Low power consumption is most critical for the sensor’s operation but is also relevant for the mobile

device. With the 430-mAh battery on the sensor, our implementation can operate for up to twelve

hours when heart rate information alone is sent. When a continuous waveform is sent, the sensor

consumes 94 mW of power on average, with 87 mW used to power the Bluetooth radio. The

transmit power of the radio has a direct effect upon the distance—that is, between the sensor and

the mobile device—at which the policy engine will detect a disconnection. Class 1 Bluetooth

devices, such as the RN-41 Bluetooth module that we adopt, have a range of approximately 100m.

As a result, the lifetime reduces to approximately two hours. This problem further motivates the

need for a policy engine, and we recommend that the ECG waveform be sent for short, bounded

periods of time and not indefinitely to maximize system lifetime. Future work to develop MBS

29

Chapter 4. Experimental Setup and Results 30

as an extremely low power integrated circuit together with low-power radio options is expected to

extend its operational runtime.

The MBS client service has approximately 4,100 source lines of C# code and has a memory

footprint of 103 KB. The mobile device used in our implementation is an HP iPAQ hx2490b with

64 MB of RAM and a 1440-mAh battery. The sensor software is 435 source lines of C which

occupy 4,308 bytes once compiled. When both receiving heart rate data and unicasting via 802.11,

the mobile device’s lifetime is approximately four and a half hours with an average CPU utilization

of 32.1%. Thus the mobile device represents a system-wide power bottleneck. These metrics may

be improved by more closely managing the 802.11 radio such that information gets buffered for

several seconds rather than sent whenever a heartbeat is detected or every 2076 bytes in the case

of an ECG signal being sent. When running in waveform mode, the mobile device CPU is almost

completely dedicated to the task. After profiling the application in waveform mode, we determined

that drawing the waveform on the screen requires 42% of the time (1663 seconds of the 3920

seconds of running time). The utilization could be significantly lowered by reducing the amount of

graphical user interface feedback.

4.1.1 Operational Mode Power Requirements

We performed several experiments in order to test the effects of radio power consumption and

operating scenarios on the lifetime and CPU utilization of the PDA. We tested the same mobile

device (the HP iPAQ hx2490b) three times for each combination of operational mode (ECG and

heart rate) and unicast setting (enabled and disabled). The heart rate scenario is when only the

heart rate is sent from the sensor and the ECG scenario is when the full ECG signal is sent from

the sensor. We obtained a baseline by having the program loaded into the memory, not doing any

computation, with both radios (Bluetooth and 802.11) off.

We find that the lifetime of the mobile device when not unicasting the heart rate information to

the web portal is suitable for extended use. Without unicasting data, the lifetime was an average

of 18.78 hours for the heart rate scenario and 7.68 hours for the ECG scenario (each with a stan-

dard deviation of less than 7 minutes). When the 802.11 radio is turned on, however, the lifetime


Idle Heart Rate ECGOperating Scenario

0

5

10

15

20

25H

ours

21.38

18.78

7.68

4.343.41

Mobile Device Lifetime

No Unicast

Unicast

(a)

Idle Heart Rate ECGOperating Scenario

0

20

40

60

80

100

CPU

Uti

lizati

on (

%)

12.3014.41

98.26

32.11

99.62

Mobile Device CPU Utilization

No Unicast

Unicast

(b)

Figure 4.1: When the 802.11 radio is turned off, the PDA battery lasts between seven and a halfhours to nineteen hours depending on the operating scenario. When the 802.11 radio is turned on,the lifetime drops to less than five hours. When sending ECG data, the CPU utilization is nearly100%.

decreases to between one-quarter and one-half of the time without the 802.11 radio turned on.

The CPU utilization is much higher for the ECG operating scenario, regardless of whether the

802.11 radio is turned on or off. It is also clear that the utilization for the ECG does not increase as

much as it does for the heart rate case. Due to the high CPU utilization, only the heart rate is sent

for both operating scenarios. Flow control performed by the operating system regulates the rate at

which data is sent and received, and thus the high contention for CPU cycles is managed by the

underlying system.

As a result of this data, we conclude that the best option to maximize lifetime and minimize

CPU utilization leverages the advantages of both operating scenarios, such that the heart rate alone

is sent the majority of time but a specified sample of the ECG is sent either periodically or on

demand (for example, when a policy action is triggered).


0 1000 2000 3000 4000 5000Samples Viewed

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

10000

Roundtr

ip T

ime (

ms)

Web Portal Performance

Figure 4.2: As the number of samples viewed increases, the average response time of the webservice increases accordingly. One sample corresponds to one heartbeat or one millisecond of ECGdata.

4.1.2 Web Portal Performance

We examined the performance of the web portal by accessing it via another computer on the same

intranet. This minimizes the effect of network latency on the measurements, emphasizing the per-

formance of the web service. We varied the number of samples viewed on the web site to test the

responsiveness of the web service, database, and XML chart data. Each experiment was run for 10

minutes, such that there were 200 requests in total, one every three seconds. We used the Firefox

3.0 browser and the YSlow and Firebug plugins to analyze the round trip times of web service re-

quests. The web service calls are performed using an encrypted (SSL) connection, so performance

is hindered relative to an unencrypted communication.

Figure 4.2 shows the trend when increasing the number of samples viewed. When viewing 100

samples, which corresponds to 100 heartbeats or 100 ms of ECG waveform data, the average round

trip time of the web service is 298 ms with a standard deviation of 90 ms. The median time is 348

ms. These statistics mean that the distribution is skewed left—a somewhat surprising result because

the response time is lower bounded by zero whereas there is no limit to how long a response could

take.

When viewing 1000 samples, the average round trip time increases to 755 ms (standard devia-

tion 614 ms) and the median time is 452 ms. This distribution is skewed right, as there are several


turnaround times greater than 1.6 seconds (20% of them). When viewing 5000 samples the average

round trip time surges to 3.577 seconds (with a standard deviation of 949 ms) and the median time

is slightly lower than the average (3.640 seconds). The response time of the site becomes notice-

ably slower as the amount of data viewed increases. Thus five seconds of data at a time, given the

constant update, is a reasonable upper bound. When the user interacts with the graph, which in-

teractively displays the sensor readings, the response time of the web service expectedly increases.

As shown by the error bars that demonstrate the range of values for each experiment, the variance

of the response times increases as the number of samples viewed increases. Thus, the turnaround

times of the web service requests become more unpredictable as more information is viewed at a

time with the constant update.

We believe that our system is sufficiently responsive to accommodate multiple users with peri-

odic data updates. Our conclusion is reinforced by the fact that the web server runs on a develop-

ment, rather than a dedicated, system. Using a dedicated system could potentially allow the number

of users to scale up and further decrease the response time.

4.2 QRS Detection

In order to detect QRS complexes, we analyzed all 48 recordings in the annotated MIT-BIH (Mas-

sachusetts Institute of Technology – Beth Israel Hospital) Arrhythmia database [50]. These half-

hour ECG signal recordings contain cardiologist annotations that indicate when beats occur and

their type (normal, premature ventricular contraction, etc.). While we recognize that the MBS

front-end apparatus does not produce these signals, we submit that the database’s ECG signals

are noisier than those produced by our system, and thus represent a challenging data set, for two

reasons. First, several of the signals from the database contain arrhythmias and other cardiac condi-

tions that make QRS detection a more difficult problem. Second, the ECG signals produced by the

MBS sensor are dynamically corrected for baseline wander before the QRS processing begins and

the common mode signals in both electrodes are removed. Therefore we contend that the results of

the QRS detection on the MIT-BIH signals are comparable or worse than if performed on signals


94.5

95

95.5

96

96.5

97

97.5

98

98.5

99

99.5

100

100101

102

103104

105

106107

108

109111

112

113114

115

116117

118

119121

122

123124

200

201202

203

205207

208

209210

212

213214

215

217219

220

221222

223

228230

231

232233

234

Positiv

e P

redic

tivity

Perc

enta

ge

Recording

QRS positive predictivity 94.5

95

95.5

96

96.5

97

97.5

98

98.5

99

99.5

100

100101

102

103104

105

106107

108

109111

112

113114

115

116117

118

119121

122

123124

200

201202

203

205207

208

209210

212

213214

215

217219

220

221222

223

228230

231

232233

234

Sensitiv

ity P

erc

enta

ge

Recording

QRS sensitivity

Figure 4.3: The average QRS sensitivity and QRS positive predictivity are over 99.5% for a totaldata set of over 109,000 beats. The signal recordings are not numbered consecutively in the MIT-BIH database.

obtained from a population tested with the MBS apparatus (which would not have the annotations

associated with them to allow comparison with a known standard).

In order to prepare the MIT-BIH signals for input to the MBS client, they were upsampled from

360 samples per second to 1000 samples per second and shifted to unsigned 16-bit values. As the

signals pass through the MBS client a log is produced that lists the R-R intervals in units of samples

between QRS complexes. We executed the bxb program [50] with default parameters (including a

150 ms match window) to compare the cardiologist annotations with the R-R interval lists produced

by the MBS client.

Our QRS detection algorithm operates on data sampled at 1000 samples per second. First each

data point is filtered through a low-pass filter, high-pass filter, and first difference filter. Then the

absolute value of the filtered data is included in a moving window integrator filter with a window

length of 80 ms. Once the data is filtered, peaks are determined and scrutinized with respect to

an adaptive threshold based on recent QRS peak values and the values of noise peaks (including

smaller deflections in the ECG, such as P-waves and T-waves).

Figure 4.3 illustrates the results of QRS detection for the 48 recordings. The sensitivity and

positive predictivity were computed as given by

Sensitivity =T P

T P+FN


Positive Predictivity =T P

T P+FP

where T P represents true positives, FN represents false negatives (missed beats), and FP represents

false positives (beats that should not have been classified as beats). We achieve an average of

99.54% QRS sensitivity (the proportion of QRS complexes correctly identified as such) and 99.79%

QRS positive predictivity (the probability that a QRS detection is correct) over all recordings. These

results are comparable to, or better than, state of the art QRS complex detectors [51]. Comparing

algorithms is somewhat difficult because some publications offer no evaluation, some do not use

standard databases (or use standard databases in a nonstandard way), and some do not present

sensitivity and positive predictivity metrics. The average root-mean-square error of the RR intervals

is 60.54 ms, well below the tolerance window of 150 ms. There are certain problematic recordings,

including recording 108 and recording 208, that possess unusual ECG characteristics. For example,

in recording 208 around the 23-minute mark, a great deal of noise is encountered in the first lead (but

not in the second) preventing any discernible QRS complex when using the first lead alone. After

the noise subsides the algorithm takes time to adapt the thresholds, causing several false negatives

and, hence, a lower QRS sensitivity. In recording 108, the QRS complexes are particularly small

relative to the P-waves and T-waves that occur at 0:20 and 28:30 into the recording. This results in

incorrect double-detection, resulting in several false positives and a lower positive predictivity.

For many ECG applications 1 kHz is more than sufficient for performing signal analysis [39].

In order to quantify the effect of reducing the processing overhead on accuracy, we reduced the

sampling rate and carried out the tests again. The benefits of reducing the sampling rate are man-

ifold. First, the processor may idle for a longer amount of time, which conserves energy. Second,

there are fewer memory requirements because the number of samples that must be stored is tied to

time, not sampling rate (and reducing the sampling rate reduces the number of samples in a unit

time period). The primary reason for not reducing the sampling rate is clinical accuracy—when

reproducing the entire ECG waveform it is important to sample relatively frequently.

Table 4.1 further shows that our heart rate algorithm is resilient to a decrease in sampling fre-

quency. We chose the lowest sampling frequency, 100 Hz, for two reasons. First, the difference


Table 4.1: Effect of Sampling Rate on Accuracy. Decreasing the sampling rate has only a slighteffect upon the average accuracy of the QRS detection on 48 signals.

Sampling Rate (Hz) Mean Sensitivity Mean Positive Predictivity R-R Error (ms)1000 99.54% 99.79% 60.55500 99.48% 99.50% 91.33250 99.40% 99.72% 72.91100 99.12% 99.09% 80.95

filter operates on 10 ms of data so sampling at 100 Hz produces one sample during that time. Sec-

ond, it is a factor of 10 smaller than 1 kHz but sampled often enough to prevent significant aliasing.

4.3 Policy Robustness

For each recording, we took the results of our QRS detection algorithm at a sampling rate of 1000

Hz and calculated the instantaneous heart rates based on the estimated R-R intervals. We found that

the instantaneous heart rates for the ECGs with arrhythmia display great variety (from less than 10

bpm to more than 305 bpm). These large variations are primarily due to arrhythmia, but noise can

also produce the same effect. Based on this information, we seek to determine acceptable threshold

levels for the policy engine to guard against being affected by arrhythmia or noise.

In order to gauge the dynamic operation of our policy engine, we examined the length of time

that heart rates were reported for each of the recordings and derived a histogram of the number of

seconds outside given thresholds. We found that on the MIT-BIH database with the cardiologist

annotations, a lower threshold of 10 bpm and an upper threshold of 187 bpm was a sufficient

window for all R-R intervals to be detected within one second. Note that although the distribution

of heart rates goes above 200 bpm, because the R-R interval time and heart rates are inversely

related, we observe that the higher the heart rate the less time it takes for the algorithm to “correct”

itself (usually less than 0.5 seconds).

There are several ways to adapt the policy engine’s functionality to be less sensitive to noise.

The first is to use a low-pass (averaging) or median filter on the heart rate signal to reduce the effect

of large swings and transient noise. The second solution is to adjust the threshold levels and the


(a) Effect of Moving Average Window on Policy Response

Window Grace Period (seconds)Length 1 5 10 151 beat 0.998 0.9998 0.99996 12 beats 0.9998 0.99996 1 14 beats 0.99993 0.99998 1 18 beats 0.99997 1 1 1

(b) Effect of Varying Sampling Rate on Policy Response

Sampling Grace Period (seconds)Rate 1 5 10 15

100 Hz 0.998 0.9998 0.99997 1250 Hz 0.998 0.9998 0.99996 1500 Hz 0.998 0.9997 0.99997 11000 Hz 0.998 0.9998 0.99996 1

Table 4.2: More than 99.97% of the MIT-BIH R-R intervals are between 273 ms and 2000 ms (220bpm and 30 bpm, respectively) for up to 5 seconds when varying either the sampling rate of theECG signal or the number of beats over which to calculate the heart rate.

threshold times. A third solution is combining both techniques, which enables a large amount of

flexibility in determining policies.

Tables 4.1(a) and 4.1(b) show four different moving average window lengths and sampling

rates, respectively, and the percentage of R-R intervals that fall within set thresholds for one, five,

ten, and fifteen seconds. We set the lower threshold at 30 bpm and the upper threshold to 220 bpm

to be indicative of rates beyond which a heart rate would be considered anomalous. As the threshold

window becomes smaller, fewer R-R intervals fall within the thresholds in less time. Raising the

lower threshold to 40 bpm and lowering the upper threshold to 100 bpm still resulted in 98.02% of

R-R intervals falling within the threshold window within 1 second. We note that sampling rate does

not have a large effect upon the operation of the policy engine. Regardless of sampling rate, the

number of intervals that fall within the threshold are about the same for each of the sampling rates.

The length of the moving average window, however, has a more significant effect. While the vast

majority of R-R intervals fall outside the thresholds for less than 1 second, the larger the window the

more quickly the R-R intervals converge. This behavior occurs because the larger window smooths

out heart rate signals, tending to cancel out the effects of extreme values. We conclude that the

potential deleterious effects of rapidly changing ECGs on the operation of the system are mitigated

by the policy engine.


4.4 Threat Analysis

Fundamentally our system intends to bring convenience and service rather than invading privacy.

We acknowledge that no system can be made perfectly secure. To justify our system design we now

discuss (1) the security mechanisms we leverage in our implementation and (2) a threat model of

the system. In our threat analysis, we proceed by first characterizing the system, then identifying

assets and access points, and finally enumerating potential threats [52].

There are three main challenges in achieving the proper balance between usability and security

within MBS. First, the entire system must have a reasonable lifetime. The sensor nodes are severely

resource-constrained and energy use is at a premium. Second, the performance of the mobile device

must not be dramatically affected by the presence of the MBS service. A process that dominates the

CPU’s cycles or drains the mobile device’s battery is not tolerable. Third, the potential faults and

transient errors must be well understood and mitigated such that the number of false event triggers

is kept at an acceptably low level.

An adversary may have several objectives in attacking a sensor-based telemedicine system com-

parable to ours. First, obtaining ECG data could be a primary goal, either to replay it later to simu-

late a user’s presence or to obtain a perspective on the wearer’s state of being. Second, because the

telemedical data is transported over the Internet, there is an incentive to eavesdrop or make copies

of the data (e.g., a man-in-the-middle attack) or break into the data repository to view medical

information through a brute force password attack, spoofing, or SQL injection. The benefit of a

heavily networked architecture is that it permits a great deal of flexibility and intercommunication,

but also calls for stiff measures to repel an increased number of attack vectors. The web service and

web portal interfaces provide an access point to a potential attacker. Furthermore, denial of service

attacks through, for example, jamming the communication links or sending spurious requests to the

sensor or mobile device to drain their batteries, represents a significant class of potential threats. In

our system, denial of service will simply cause a Disconnection or Timeout event and sleep depriva-

tion torture is difficult because once the Bluetooth radio is connected, it does not respond to service

inquiries. We note that in an emergency scenario, a denial of service could be life threatening.


The foremost challenge for establishing the authenticity of the ECG waveform is establishing

the origin of the signal. Since the validation process on the mobile device is not tightly coupled

with the sensor, we must be able to have some amount of confidence that the signal is authentic. In

other words, we must guard against an adversary replaying a previously recorded reading with an

attack tool. The first aspect of an attack must be proximity—the attacker must be within range of

the radio. The requirement of proximity can also limit more subtle attacks based on traffic analysis

and surveillance. The second aspect of an attack is the strength of the bond between sensor and

mobile device. MBS uses encryption and a PIN code to assist in protecting against replays through

mutual authentication. In this case readings that are played from untrusted components are ignored.

4.5 Summary

Our policy engine enables efficient tradeoffs between the components of the system. Our system is

capable of providing an end-to-end “control plane” in which data is exchanged bidirectionally by

means of an adaptive policy engine. The sensor accurately detects heartbeats and the mobile de-

vice enforces policies, based on properties of the sensor connection and the sensor information, to

promote efficient cross-system tradeoffs. Specifically, we have shown that the system has sufficient

lifetime under reasonable assumptions for operation, high signal fidelity when necessary (with ac-

curate signal processing algorithms to assist), and adequate security by demonstrating the process

of our implementation and analyzing the potential threats to the system. MBS can make use of the

physiological data in multiple ways because of the flexibility of the policy engine and the acceptable

power, performance, and QRS detection accuracy results.

Chapter 5

Conclusions and Future Work

In this thesis we addressed the problem of remote medical monitoring, particularly the problem

of how to approach the operation of sensors in the context of desired global system behavior. In

Chapter 2 we discussed the shortcomings of other system architectures, detailed how dependability

and signal processing are pertinent issues in remote medical monitoring design, and placed our

system into context. In Chapter 3 we presented the three-tier architecture and the policy engine. We

proposed the success criteria and evaluation process in Chapter 4 and analyzed the results.

5.1 Conclusions

We have presented MBS, a novel, policy-driven approach to managing the operation of remote

medical monitoring. Our policy engine is a general-purpose idea that could accommodate several

purposes, one of which is a remote medical monitoring application as examined in this thesis. We

have shown that our QRS detection algorithm has sufficient accuracy to be used as input to a policy.

We have evaluated the use of averaging windows in providing continuity of service in spite of local

anomalous events and noise. While flexibility and configurability are important attributes of the

system, intelligent defaults lead to a convenient off-the-shelf implementation.

40

Chapter 5. Conclusions and Future Work 41

5.2 Present and Future Work

Our latest work on an ultra low-power ECG sensor has dramatically reduced the power consumption

of the sensor. The analog and digital components have been integrated into a system-on-chip (SoC)

that acquires and processes an ECG signal using sub-threshold logic [53]. The microcontroller

operates from 0.24 V to 1.2 V and consumes as little as 1.51 pJ per instruction. The SoC, not

including the radio, consumes only 2.6 µW of power and the heart rate algorithm performs well

(100% sensitivity) on a representative ECG waveform. Our next goal is to interface the SoC with a

low-power radio such that the sensor can communicate data wirelessly.

The prospects of MBS software, and particularly the policy engine, go much further than just

remote monitoring, as applications to healthcare and security will be more fully explored in several

directions. The ability to control operation dynamically based on inferred context is a powerful

idea. Now, the sensor can be controlled with explicit user feedback but ideally the management of

sensors will be fully automated and the system will know automatically when particular modes of

operation should be invoked. An operating system for body area sensors that could handle modular

“bundles,” each of which provides a set of services that seamlessly integrates with one another

to maximize lifetime and system utility has yet to be demonstrated. We intend to explore energy

scavenging [54] to make the sensor operation as autonomous as possible. Work in the area of

power harvesting often possesses assumptions that are particular to a specific scenario and neglect

to consider the communication of sensors in their models. A general model for energy scavenging

in body sensor network applications has yet to be developed that can accommodate the demands of

dynamic power usage.

While the ECG signal provides useful information for analyzing an individual’s state of health,

a richer view can be gained with multiple sensors, including sensors for the body and sensors for

the environment. We envision a hardware platform in which sensors may be dynamically switched

in and out with accompanying software that keeps everything in order. Furthermore, there is in-

teresting work being done in determining the right programming abstractions for cyber-physical

systems and how to address security within them. With multiple signals and inherently concurrent

Chapter 5. Conclusions and Future Work 42

operation, more sophisticated algorithms for processing should allow correlations to be made, with

adverse events being validated by other signals before being reported to reduce errors. The presence

of multiple signals could make the overall system more reliable and robust, and it could improve the

quality of our system. Furthermore, the availability of multiple body-derived signals may enable

new ways to authenticate. As sensors become smaller and fade into the world around us, we can

leverage them for remote medical monitoring and for future, unknown applications.

Bibliography

[1] G. Bell. The body electric. Commun. ACM, 40(2):30–32, February 1997.

[2] Milken Institute. An unhealthy America: Economic burden of chronic disease. http://www.

chronicdiseaseimpact.com/, October 2007.

[3] National Center for Chronic Disease Prevention and Health Promotion. Chronic disease

overview. http://www.cdc.gov/NCCdphp/overview.htm, November 2008.

[4] National Academy of Engineering. Grand challenges for engineering. http://www.

engineeringchallenges.org/, 2008.

[5] K. Lorincz, D. J. Malan, T. R. Fulford-Jones, A. Nawoj, A. Clavel, V. Shnayder, G. Main-

land, M. Welsh, and S. Moulton. Sensor networks for emergency response: challenges and

opportunities. IEEE Pervasive Comput., 3(4):16–23, October 2004.

[6] A. Wood, G. Virone, T. Doan, Q. Cao, L. Selavo, Y. Wu, L. Fang, Z. He, S. Lin, and

J. Stankovic. ALARM-NET: Wireless sensor networks for assisted-living and residential

monitoring. Technical Report CS-2006-13, Department of Computer Science, University of

Virginia, 2006.

[7] Social Security and Medicare Boards of Trustees. A summary of the 2008 annual reports.

http://www.ssa.gov/OACT/TRSUM/index.html, April 2008.

[8] R. B. Altman. Informatics in the care of patients: ten notable challenges. Western J. Med.,

166(2):118–122, February 1997.

43

http://www.chronicdiseaseimpact.com/

http://www.chronicdiseaseimpact.com/

http://www.cdc.gov/NCCdphp/overview.htm

http://www.engineeringchallenges.org/

http://www.engineeringchallenges.org/

http://www.ssa.gov/OACT/TRSUM/index.html

Bibliography 44

[9] A. D. Jurik and A. C. Weaver. Remote medical monitoring. IEEE Computer, 41(4):96–99,

April 2008.

[10] A. D. Jurik and A. C. Weaver. Control, analysis, and visualization of body sensor streams.

In Int’l Symposium on Medical Information and Communication Technology (ISMICT), Mon-

treal, Canada, February 2009.

[11] M. Blount, V. M. Batra, A. N. Capella, M. R. Ebling, W. F. Jerome, S. M. Martin, M. Nidd,

M. R. Niemi, and S. P. Wright. Remote health-care monitoring using Personal Care Connect.

IBM Systems Journal, 46(1):95–113, January 2007.

[12] D. Jea and M. Srivastava. A remote medical monitoring and interaction system. Technical

Report TR-UCLA-NESL-200511-03, University of California, Los Angeles, November 2005.

[13] J. K. Pollard, M. E. Fry, S. Rohman, C. Santarelli, A. Theodorou, and N. Mohoboob. Wireless

and web-based medical monitoring in the home. Medical Informatics and the Internet in

Medicine, 27(3):219–227, September 2002.

[14] K. Hung and Y.-T. Zhang. Implementation of a WAP-based telemedicine system for patient

monitoring. IEEE Trans. Inf. Technol. Biomed., 7(2):101–107, June 2003.

[15] T. Gao, D. Greenspan, M. Welsh, R. R. Juang, and A. Alm. Vital signs monitoring and patient

tracking over a wireless network. In Int. Conf. of the IEEE Engineering in Medicine and

Biology Society, pages 102–105, Shanghai, China, September 2005.

[16] N. Dokovsky, A. van Halteren, and I. Widya. BANip: Enabling remote healthcare monitoring

with body area networks. In Scientific Engineering of Distributed Java Applications, pages

62–72, Luxembourg-Kirchberg, Luxembourg, November 2004.

[17] K. J. Liszka, M. A. Mackin, M. J. Lichter, D. W. York, D. Pillai, and D. S. Rosenbaum.

Keeping a beat on the heart. IEEE Pervasive Comput., 3(4):42–49, October 2004.

[18] Center For Future Health, University of Rochester. Smart medical home research laboratory.

http://www.futurehealth.rochester.edu/smart_home/index.html, 2005.

http://www.futurehealth.rochester.edu/smart_home/index.html

Bibliography 45

[19] CardioNet. http://www.cardionet.com/, September 2008.

[20] Medtronic CareLink Network. http://www.medtronic.com/carelink/, September 2008.

[21] Biotronik Home Monitoring. http://www.biotronik-healthservices.com/sixcms/

detail.php?id=136, September 2008.

[22] C. Park, P. H. Chou, Y. Bai, R. Matthews, and A. Hibbs. An ultra-wearable, wireless, low

power ECG monitoring system. In IEEE Biomedical Circuits and Systems Conf., London,

United Kingdom, November 2006.

[23] A. D. Jurik and A. C. Weaver. Body area networks: wireless access to physiological data.

IEEE Software, 26(1):71–73, January 2009.

[24] U. Anliker, J. A. Ward, P. Lukowicz, G. Tröster, F. Dolveck, M. Baer, F. Keita, E. B. Schenker,

F. Catarsi, L. Coluccini, A. Belardinelli, D. Shklarski, M. Alon, E. Hirt, R. Schmid, and

M. Vuskovic. AMON: a wearable multiparameter medical monitoring and alert system. IEEE

Trans. Inf. Technol. Biomed., 8(4):415–427, December 2004.

[25] D. Lucani, G. Cataldo, J. Cruz, G. Villegas, and S. Wong. A portable ECG monitoring device

with Bluetooth and Holter capabilities for telemedicine applications. In Int. Conf. of the IEEE

Engineering in Medicine and Biology Society, pages 5244–5247, New York City, NY, USA,

August 2006.

[26] B. Gyselinckx, R. Vullers, C. V. Hoof, J. Ryckaert, R. F. Yazicioglu, P. Fiorini, and V. Leonov.

Human++: Emerging technology for body area networks. In IFIP Int. Conf. on Very Large

Scale Integration & System-on-Chip, pages 175–180, Nice, France, October 2006.

[27] R. K. Ganti, P. Jayachandran, T. F. Abdelzaher, and J. A. Stankovic. SATIRE: a software

architecture for smart attire. In Int. Conf. on Mobile Systems, Applications and Services,

pages 110–123, Uppsala, Sweden, June 2006.

http://www.cardionet.com/

http://www.medtronic.com/carelink/

http://www.biotronik-healthservices.com/sixcms/detail.php?id=136

http://www.biotronik-healthservices.com/sixcms/detail.php?id=136

Bibliography 46

[28] T. Martin, E. Jovanov, and D. Raskovic. Issues in wearable computing for medical monitoring

applications: a case study of a wearable ECG monitoring device. In Int’l Symp. on Wearable

Computers, pages 43–49, Atlanta, GA, USA, October 2000.

[29] M. Steffen, A. Aleksandrowicz, and S. Leonhardt. Mobile noncontact monitoring of heart and

lung activity. IEEE Trans. Biomed. Circuits Syst., 1(4):250–257, December 2007.

[30] A. Avižienis, J.-C. Laprie, B. Randell, and C. Landwehr. Basic concepts and taxonomy of

dependable and secure computing. IEEE Trans. Dependable Secure Comput., 1(1):11–43,

January 2004.

[31] J.-P. Hubaux, L. Buttyán, and S. Capkun. The quest for security in mobile ad hoc networks.

In ACM Int’l Symp. on Mobile Ad Hoc Networking and Computing, Long Beach, CA, USA,

October 2001.

[32] F. Stajano and R. Anderson. The Resurrecting Duckling: security issues for ubiquitous com-

puting. IEEE Computer, 35(4):22–26, April 2002.

[33] M. Satyanarayanan. Pervasive computing: vision and challenges. IEEE Personal Commun.

Mag., 8(4):10–17, August 2001.

[34] J. C. Knight. An introduction to computing system dependability. In Int. Conf. on Software

Engineering, pages 730–731, Edinburgh, Scotland, UK, May 2004.

[35] Samuel J. Dwyer III, A. C. Weaver, and K. K. Hughes. Health Insurance Portability and

Accountability Act, chapter 2, pages 9–18. Society for Computer Applications in Radiology,

2004.

[36] D. Halperin, T. Kohno, T. S. Heydt-Benjamin, K. Fu, and W. H. Maisel. Security and privacy

for implantable medical devices. IEEE Pervasive Comput., 7(1):30–39, January 2008.

[37] D. Halperin, T. S. Heydt-Benjamin, B. Ransford, S. S. Clark, B. Defend, W. Morgan, K. Fu,

T. Kohno, and W. H. Maisel. Pacemakers and implantable cardiac defibrillators: Software

Bibliography 47

radio attacks and zero-power defenses. In IEEE Symp. on Security and Privacy, pages 129–

142, Oakland, CA, USA, May 2008.

[38] A. Sabelfeld and A. C. Myers. Language-based information-flow security. IEEE J. Sel. Areas

Commun., 21(1):5–19, January 2003.

[39] G. D. Clifford, F. Azuaje, and P. E. McSharry. Advanced Methods and Tools for ECG Data

Analysis. Artech House, Norwood, MA, USA, 2006.

[40] G. Wübbeler, M. Stavridis, D. Kreiseler, R.-D. Bousseljot, and C. Elster. Verification of

humans using the electrocardiogram. Pattern Recogn. Lett., 28(10):1172–1175, July 2007.

[41] L. Biel, O. Pettersson, L. Philipson, and P. Wide. ECG analysis: a new approach in human

identification. IEEE Trans. Instrum. Meas., 50(3):808–812, June 2001.

[42] S. A. Israel, J. M. Irvine, A. Cheng, M. D. Wiederhold, and B. K. Wiederhold. ECG to identify

individuals. Pattern Recogn., 38(1):133–142, May 2004.

[43] S. Kumar, T. Sim, R. Janakiraman, and S. Zhang. Using continuous biometric verification to

protect interactive login sessions. In Computer Security Applications Conf., pages 441–450,

Tucson, AZ, USA, December 2005.

[44] C. C. Poon, Y.-T. Zhang, and S.-D. Bao. A novel biometrics method to secure wireless body

area sensor networks for telemedicine and m-health. IEEE Commun. Mag., 44(4):73–81, April

2006.

[45] J. Pan and W. J. Tompkins. A real-time QRS detection algorithm. IEEE Trans. Biomed. Eng.,

BME-32(3):230–236, March 1985.

[46] P. S. Hamilton and W. J. Tompkins. Quantitative investigation of QRS detection rules us-

ing the MIT/BIH arrhythmia database. IEEE Trans. Biomed. Eng., BME-33(12):1157–1165,

December 1986.

Bibliography 48

[47] G. M. Friesen, T. C. Jannett, M. A. Jadallah, S. L. Yates, S. R. Quint, and H. T. Nagle. A

comparison of the noise sensitivity of nine QRS detection algorithms. IEEE Trans. Biomed.

Eng., 37(1):85–98, January 1990.

[48] C. Meyer, J. F. Gavela, and M. Harris. Combining algorithms in automatic detection of QRS

complexes in ECG signals. IEEE Trans. Inf. Technol. Biomed., 10(3):468–475, July 2006.

[49] B. Shneiderman. The eyes have it: a task by data type taxonomy for information visualiza-

tions. In IEEE Symp. on Visual Languages, pages 336–343, Boulder, CO, USA, September

1996.

[50] A. L. Goldberger, L. A. N. Amaral, L. Glass, J. M. Hausdorff, P. C. Ivanov, R. G. Mark, J. E.

Mietus, G. B. Moody, C.-K. Peng, and H. E. Stanley. PhysioBank, PhysioToolkit, and Phys-

ioNet: Components of a new research resource for complex physiologic signals. Circulation,

101(23):e215–e220, June 2000.

[51] B.-U. Köhler, C. Hennig, and R. Orglmeister. The principles of software QRS detection. IEEE

Eng. Med. Biol. Mag., 21(4):42–57, January 2002.

[52] S. Myagmar, A. J. Lee, and W. Yurcik. Threat modeling as a basis for security requirements.

In Symp. on Requirements Engineering for Information Security, Paris, France, August 2005.

[53] B. H. Calhoun, J. Bolus, S. Khanna, A. D. Jurik, A. C. Weaver, and T. N. Blalock. Sub-

threshold operation and cross-hierarchy design for ultra low power wearable sensors. In IEEE

Int’l Symposium on Circuits and Systems (ISCAS), Taipei, Taiwan, May 2009.

[54] J. A. Paradiso and T. Starner. Energy scavenging for mobile and wireless electronics. IEEE

Pervasive Comput., 4(1):18–27, January 2005.

biotelemetry and body sensors: enabling ecg · pdf filebiotelemetry and body sensors: enabling...

Documents