Upload
phambao
View
235
Download
3
Embed Size (px)
Citation preview
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
Chapter 1. Introduction 3
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.
Chapter 1. Introduction 4
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.
Chapter 1. Introduction 5
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
Chapter 1. Introduction 6
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.
Chapter 1. Introduction 7
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-
Chapter 2. Related Work 10
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
Chapter 2. Related Work 11
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
Chapter 2. Related Work 12
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
Chapter 2. Related Work 13
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
Chapter 2. Related Work 14
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
Chapter 2. Related Work 15
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
Chapter 2. Related Work 16
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
Chapter 2. Related Work 17
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,
Chapter 3. System Architecture 20
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-
Chapter 3. System Architecture 21
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
Chapter 3. System Architecture 22
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
Chapter 3. System Architecture 23
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.
Chapter 3. System Architecture 24
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.
Chapter 3. System Architecture 25
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
Chapter 3. System Architecture 26
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
Chapter 3. System Architecture 27
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
Chapter 3. System Architecture 28
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
Chapter 4. Experimental Setup and Results 31
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).
Chapter 4. Experimental Setup and Results 32
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
Chapter 4. Experimental Setup and Results 33
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
Chapter 4. Experimental Setup and Results 34
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
Chapter 4. Experimental Setup and Results 35
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
Chapter 4. Experimental Setup and Results 36
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
Chapter 4. Experimental Setup and Results 37
(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.
Chapter 4. Experimental Setup and Results 38
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.
Chapter 4. Experimental Setup and Results 39
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
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.
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.
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.