Wireless Sensor Networks for Healthcare Applications

Wireless Sensor Networks for Healthcare Applications

For a listing of recent titles in the Artech House Telemedicine and Connected Health, Technology Series turn to the back of this book.

Wireless Sensor Networks for Healthcare Applications Terrance J. Dishongh Michael McGrath

artechhouse.com

Library of Congress Cataloging-in-Publication Data A catalog record for this book is available from the U.S. Library of Congress.

British Library Cataloguing in Publication Data A catalogue record for this book is available from the British Library.

ISBN-13: 978-1-59693-305-7

Cover design by Pilar Colleran © 2010 Intel. All rights reserved. Artech House 685 Canton Street Norwood, MA 02062 Printed and bound in the United States of America. No part of this book may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage and retrieval system, without permission in writing from the publisher. All terms mentioned in this book that are known to be trademarks or service marks have been appropriately capitalized. Artech House cannot attest to the accuracy of this information. Use of a term in this book should not be regarded as affecting the validity of any trademark or service mark.

10 9 8 7 6 5 4 3 2 1

Contents Acknowledgments

xi

CHAPTER 1 Healthcare and the Wireless Sensor Network

1

1.1 1.2 1.3 1.4

Introduction Structure The Demographic Context The Potential of Technology 1.4.1 Sensor Networks for At-Home Care 1.4.2 Wireless Biomedical Sensor Networks 1.4.3 Value to Clinicians and Caregivers 1.4.4 Benefits of At-Home WSNs 1.5 General Approach to WSN in Healthcare 1.5.1 Key Principles 1.5.2 Methodology 1.6 Conclusion References

1 1 2 5 6 7 8 8 9 9 9 11 11

CHAPTER 2 Sensor Network Technologies

13

2.1 Introduction 2.2 Wireless Sensor Networks 2.2.1 Network Architectures 2.2.2 TCP/IP and WSNs 2.3 WSN Technologies 2.3.1 Motes 2.3.2 MICA 2.3.3 iMote 2.3.4 Microcontrollers 2.3.5 Radio Transceivers 2.3.6 Radios for WSN Applications 2.3.7 System-on-Chip 2.3.8 Antenna Designs for Wireless Sensors 2.3.9 Operating Systems 2.3.10 Sensors and Actuators for Healthcare WSNs 2.4 Conclusion References

13 13 14 16 16 18 19 20 20 24 25 29 29 33 34 36 39

v

vi

Contents

CHAPTER 3 Informing Your Design

45

3.1 Introduction 3.2 Clinician Requirements 3.2.1 Data to Be Collected 3.2.2 Information Reporting 3.2.3 Subject Interaction 3.2.4 Environment 3.2.5 Sample CRD Contents 3.3 End User Modeling 3.3.1 User Definition: The Role of Ethnography 3.3.2 Ethnographic Modeling 3.3.3 Ethnography: Conclusion 3.4 Usage Modeling 3.4.1 The Usage Modeling Process 3.4.2 Benefits of Usage Modeling 3.5 Requirements 3.5.1 Use Cases 3.6 Failure Modes and Effects Analysis 3.6.1 FMEA Example #1 3.6.2 FMEA Example #2 3.7 Conclusion 3.8 Field Experience: Furniture Cruising References Select Bibliography

45 46 46 46 47 47 48 49 49 50 51 52 52 54 54 54 55 56 56 59 60 61 61

CHAPTER 4 Technology Selection

63

4.1 Introduction 4.2 Practical Guidelines for Architecting WSN Solutions for Healthcare 4.2.1 Generalized WSN Architecture for Healthcare 4.2.2 Literature Highlights: Architectural Models 4.3 From Requirements Statement to Technology Selection 4.4 Hardware Choices 4.4.1 Selection Criteria 4.4.2 Relevant Clinical Research 4.4.3 Off-the-Shelf, or Bespoke? 4.4.4 Two-Chip or Single-Chip? 4.4.5 Documentation Is Essential: The PDRD 4.4.6 Hardware Prototyping and Design Review 4.5 Firmware Choices 4.5.1 RTOS or Simple Scheduler? 4.5.2 Operating System 4.5.3 TinyOS 4.5.4 Communications Standards: ISO/IEEE 11073 4.6 Software Choices 4.6.1 Software Considerations

63 63 64 65 67 68 68 71 72 72 73 75 76 76 76 76 81 82 82

Contents

vii

4.6.2 Programming Languages 4.6.3 IDE and Compilers 4.6.4 Transparency of Source Code 4.6.5 Data Management 4.6.6 Conclusion 4.7 Field Experience #1: Radio Enclosures 4.8 Field Experience #2: Bluetooth Testing 4.8.1 Introduction 4.8.2 Experimental Process 4.8.3 Results 4.8.4 Conclusions References Useful Links

84 84 84 84 85 85 89 89 89 92 92 93 94

CHAPTER 5 Data Collection and Decision Making

95

5.1 Introduction to Inference Modeling 5.1.1 Categories of Inference Engines 5.1.2 Limitations of Predictive Analytics 5.2 Static Rules-Based Models 5.2.1 Example of a Static Rules-Based Application 5.3 Statistical Probability Models 5.4 Bayesian and Markov Models 5.4.1 Field Experiences ADL Applications References

95 96 97 97 99 100 100 104 105

CHAPTER 6 Deploying in the Field

107

6.1 Introduction 6.2 Planning 6.3 Testing 6.3.1 Bench Testing 6.3.2 Lab Testing 6.3.3 Friendly Environment Test 6.3.4 Ethical Review and Labeling 6.3.5 Premarket Testing 6.3.6 Documentation 6.4 Preinstall 6.5 Installation 6.6 Maintenance 6.7 Teardown 6.8 Field Experience 6.8.1 Planning 6.8.2 Choice of Radio 6.8.3 Installation 6.8.4 Building Materials 6.8.5 Participant Tests

107 107 108 109 110 111 111 113 113 113 114 115 116 117 117 117 120 120 122

viii

Contents

6.8.6 Human Frailty 6.8.7 Fluorescent Lamps and Infrared References

123 123 123

CHAPTER 7 Clinical Deployments of Wireless Sensor Networks: Gait

125

7.1 Introduction 7.2 Clinical Problem Statement 7.3 Clinical Research Objective 7.3.1 Technology Objective 7.4 Clinician Requirements 7.4.1 User Definitions and Permissions 7.4.2 Clinical Parameters 7.4.3 Data Collection and Storage 7.4.4 Data Analysis and Reporting 7.4.5 Subject Interaction 7.5 Ethnography and Usage Modeling 7.6 Environmental Issues 7.7 Technology Selection Criteria 7.8 Technology Selection 7.8.1 Device 7.8.2 Sensor Technology 7.8.3 Radio 7.8.4 Footfall Mapping Technology 7.8.5 Video Cameras and System Layout 7.8.6 Software 7.9 Prototype Definitions Requirements Document 7.9.1 Purpose of PDRD 7.9.2 System Description: Footfall Sensor 7.9.3 System Description: Body-Worn Sensors 7.9.4 System Description: Software 7.9.5 System Description: Video 7.9.6 System Description: Miscellaneous Sensors 7.10 System Validation 7.11 Conclusion References

125 125 126 126 127 127 128 130 130 132 132 133 133 134 135 135 135 135 136 136 136 137 137 141 143 145 145 145 147 147

CHAPTER 8 Contextual Awareness Medication Prompting Field Trials in Homes

151

8.1 Introduction 8.2 Problem Statement 8.2.1 Medication Reminders 8.3 Research Objective 8.4 Ethnographic Research on Medication Routines 8.5 Probe Study: Three Existing Medication Reminders 8.5.1 Probe Study Participants 8.5.2 Probe Study Procedure

151 151 152 152 153 154 156 156

Contents

8.6 8.7 8.8

8.9 8.10 8.11

8.12

8.13 8.14

8.15

ix

8.5.3 Probe Study Results and Discussion 8.5.4 Device Preferences Collaborative Design Ethnographic, Probe Study, and Collaborative Design Results Use Cases 8.8.1 Use Case #1 8.8.2 Use Case #2 8.8.3 Use Case #3 Technical Design Technology Selection Prototype Definition Requirements Document 8.11.1 System Description: iMedTracker 8.11.2 System Description: Health SPOT 8.11.3 System Description: Activity Beacon 8.11.4 System Description: Phone Sensor 8.11.5 System Description: Bed Sensor 8.11.6 System Description: Motion Sensor 8.11.7 System Description: Door Sensor Software: The Inference Engine 8.12.1 The Total Set of Activities to Be Detected or Inferred 8.12.2 Activities Affecting Adherence 8.12.3 Activities Affecting Ability to Respond to Prompts 8.12.4 Other Significant Effects to Detect 8.12.5 Some Candidate Effects Not Detected 8.12.6 Sensors and Actuators to Be Deployed 8.12.7 Types of Inference Reasoning System for Context-Aware Prompting Explanation of Location Tracking Using the Health SPOT Watch 8.14.1 Literature Review 8.14.2 RSSI and BER for Location 8.14.3 Health SPOT Device Construction and Software 8.14.4 Prompting Stack Pseudocode Conclusion References

CHAPTER 9 Case Study: Social Health 9.1 9.2 9.3 9.4 9.5 9.6

Introduction Clinical Problem Statement Clinical Research Objective Technology Objectives System Architecture Requirements Capture and User Modeling 9.6.1 Clinical Requirements 9.6.2 Usage Models 9.6.3 Data to Be Collected 9.6.4 Subject Interaction

158 158 160 162 162 162 163 163 163 163 166 166 174 180 182 183 184 185 185 185 186 186 186 186 187 187 190 193 194 195 195 200 200 201

205 205 205 206 206 207 207 208 209 210 210

x

Contents

9.6.5 Environment 9.7 Technology Selection Criteria 9.8 Technology Selection 9.8.1 Mote 9.8.2 Door Sensors 9.8.3 Motion Sensors 9.8.4 Location Sensors 9.8.5 Presence Lamp 9.8.6 Software 9.9 Deployment 9.9.1 Radio Enclosures 9.9.2 Infrared Location Tracking Issues 9.9.3 Building Materials 9.9.4 Pets 9.9.5 Every House Is Different 9.10 Results 9.11 Conclusion References Select Bibliography

211 211 212 212 212 212 213 215 215 219 219 220 221 222 222 222 223 223 223

CHAPTER 10 Future of Wireless Sensor Networks for Healthcare

225

10.1 Introduction 10.2 Noncontact Sensing: The Burnfoot Project 10.2.1 Incorporation of Derivation Findings into Burnfoot 10.2.1 Sensor Simulations 10.2.2 Potential Applications 10.2.3 Burnfoot Validation 10.3 Using Radio Frequency for the Biosignals Data Collection 10.3.1 Leveraging the Doppler Effect 10.4 Movement to Standardized Radios for WSN 10.5 Ubiquitous Displays 10.6 Conclusion References

225 225 230 231 233 234 235 235 236 236 236

Index

239

Acknowledgments The information contained within our text comes from the efforts and the dedication of many researchers both academic institutions and industrial companies, as well as those who volunteered to allow us to trial the technology with them. The authors would like to thank Steve Agritelley, Steven M. Ayer, Benjamin Kuris, Eric Dishman, Farzin Guilak, Beth Logan, Jay Lundell, Kevin Rhodes, Margie Morris, Stuart Smith, Brad Needham, Sengul Vurgun, Matthai Philipose, Misha Pavel, KoW Cobbinah, Tamara Hayes, Jeffrey Kaye, Janna Kimel, Michael Lambhard, Bill DeLeeuw, Niamh Scannell, Adrian Burns, Charing Riolo, Grainne Miller, John Sherry, Simon Roberts, David Pendragast, Cliodhna Ní Scanaill, Karol O’Donovan, Julie Behan, Paddy Nixon, Seamus Small, Aaron Quigley, Charing Riolo, Damien Kelly, Fergal Tuffy, Phillip Vance, Barry Greene, Chen Wie (Mimi) Fan, Mike Forgarty, and a special thanks to Ciaran Clissman and Jeannine Drew for editing and helping with the construction. To show our appreciation and acknowledgement, we the authors have asked that the publisher donate all authorship royalties to the Alzheimer’s Association.

xi

CHAPTER 1

Healthcare and the Wireless Sensor Network 1.1

Introduction In this book, the authors capture a broad spectrum of knowledge gained by conducting numerous healthcare trials in clinical and home settings using wireless sensors networks. The general problem of acquiring physiological and behavioral data from patients for diagnosis, monitoring, or chronic disease management can be addressed using wireless sensors. Within this text the authors have collected the best known methods, technology assessments, and training to teach and inform the reader, based on experience and knowledge collected over the last 10 years “in the trenches.”

1.2

Structure This book consists of 10 chapters. Chapter 1 begins by presenting the book structure. It continues by reviewing the changing demographic of the worldwide aging population and its impact on the healthcare systems of countries around the world. The potential value of moving the point of routine monitoring and care from hospitals into the home is highlighted. The role of technology in supporting independent aging in the home is then examined, with an emphasis on the use of wireless sensor networks. Finally, the overall methodology used by the authors for planning, building, and deploying WSNs for healthcare is presented; this methodology is further developed throughout this book. Chapter 2 focuses on the technologies available to the engineer who is designing, building, and deploying a WSN in support of a healthcare objective. Dedicated sections look at overall system architectures, as well as available technologies in sensors and actuators, microprocessors, radio stacks, operating systems, and antennas. The critical importance of antenna choice for WSNs is highlighted. Chapter 3 examines the capture of systems requirements for at-home healthcare solutions and the collection of information required for the solution design. The overall clinical requirements for the solution are provided by the clinician to the engineer in a clinical requirements document (CRD). A key issue is ensuring the system meets the needs of an older person living at home. Ethnographic observation and analysis are introduced and their potential is explored. Usage modeling, which

1

2

Healthcare and the Wireless Sensor Network

aims to analyze the overall end user experience, is also considered. A discussion of technical design considerations (data to be collected, information to be reported, etc.) follows. Failure modes and effects analysis (FMEA) can productively be used to minimize failures and their impact on a WSN resource. This topic is explored with supporting examples. The theoretical material is illustrated with a case study of the use of ethnography in a recent at-home healthcare project. Chapter 4 explores how to select the best possible combination of technologies to implement the solution. The creation of an appropriate systems architecture, taking all relevant issues into account, is explored. Dedicated sections look at selecting hardware, firmware, and software for WSN solutions. Two case studies illustrate the process in some detail. Chapter 5 considers the use of machine learning and rules-based inference for the analysis of sensor data. Data analysis for sensor network solutions must support both long-term trending and also real-time decision making, triggering actuation. The amount of data being collected can be quite substantial; analysis of these data sets using an expert system is a promising research area. Chapter 6 describes how to test, finalize, and deploy a WSN solution in a home environment. There is a strong focus on the testing process, including bench, lab, friendly and premarket testing, labeling, and human subjects review. A detailed step-by-step guide to installations, from planning to final teardown, is provided, informed by the authors’ experiences of real-world deployments. Chapter 7 documents for the reader the creation of a wireless sensor platform for clinical applications as a case study for a system for clinical evaluation of gait. The chapter takes the reader through the development lifecycle of a wireless platform called SHIMMER from the conceptual design phase through to the clinical application of the platform. It offers a valuable insight into the various phases of the SHIMMER project lifecycle and the lessons learned along the way. The system is installed in three world-class clinics located in different parts of the globe with over 600 patients assessed by the systems to date. Chapter 8 contains a different application of wireless sensor network for medication reminding in the home. The system was deployed in the homes of 15 elderly subjects in the United States. The findings from these field trials are described for the reader. Chapter 9 covers a second trial in the homes of elderly subjects in the United States that sought to demonstrate the effectiveness of social connectivity between the elderly and their social network of friend and family. The trial reviewed in this chapter was conducted with 12 caregivers and elderly in the western part of the United State. Concluding the book, Chapter 10 attempts to give the reader a glimpse into future trends of healthcare and the potential impact of body sensor networks to those trends.

1.3

The Demographic Context The global population is getting older. Throughout the western world, people are living longer. The length of retirement is increasing, as is the length of time that

1.3 The Demographic Context

3

people live with chronic diseases such as heart disease, cancer, Alzheimer’s, and other forms of dementia. This places enormous demands on healthcare systems, not solely in terms of acute hospital care but also for routine monitoring and health maintenance on a massive scale. Some 861 million people worldwide with chronic diseases are using up to 85% of healthcare dollars. Currently government spending in the United States on health runs at more than $1.5 trillion per annum. This level of expenditure has resulted in enormous financial difficulties for government in its efforts to provide both prescription drug and social security benefits to its growing elderly population. The current situation is likely to worsen due to the fact that it is less than 10 years before the first baby boomers reach retirement age. This will herald an era when the elderly population is for the first time expected to outnumber the young [1]. This is not unique to the United States but is in fact a global trend. The worldwide population over age 65 is expected to more than double from 357 million in 1990 to 761 million by 2025 [2]. In 1950, all European countries had an elderly population (age 65+) of some 45 million; in 1995, the population age 65+ had already more than doubled to 101 million; and by 2050, Europe will have 173 million people age 65 and above [3] (see Figure 1.1). The picture in the United States is similar to that in Europe. Figure 1.2 shows the U.S. population growth for three different age groups from 1975 to 2025. The overall population increase over this period is about 60%, from almost 216 million in 1975 to close to 350 million projected in 2025. However, the percentage of the population under age 65 declines, and the percentage age 65 and older increases from 10.6% in 1975 to 18.2% in 2025. Older adults already constitute one-fifth of the total population of much of Western Europe and Japan. In many countries, the ratio of workers to retirees will drop to 2:1. This will profoundly affect national economies and business productivity (Figure 1.3). Population of Europe by Age Group 200

150

100

Age 65+ Age 15-64 Age 0-14

50

0

Figure 1.1

1995

2005 Year

2050

Age distribution of European population in 1995, 2025, and 2050.

4

Healthcare and the Wireless Sensor Network

400 350 300 250 200

Age 65+ Age 15-64 yrs Age 0-14 yrs

150 100 50 0 2050

2005 Year

1975

Figure 1.2 U.S. population growth of three age groups for 1975, 2000, and projected for 2025. The elderly segment is increasing almost twice as fast as the rest of the population. (Source: U.S. Census Bureau.)

Public Expenditures on Health 1998–2006 14 12 10 8 6 4 2 0

Figure 1.3 Children).

1998

1999

2000

2001

2002 Year

2003

2004

2005

2006

Irish government spending on health 1997–2006 (Source: Department of Health and

1.4 The Potential of Technology

5

Meanwhile, longevity has given rise to expensive age-related disabilities and diseases, such as Alzheimer’s. In addition to the standard medical treatment for these conditions, a 1997 study found that almost one-third of U.S. adults, most of whom also held full-time jobs, were serving as informal caregivers—mostly to an elderly parent [4]. The 1997 cost of replacing this assistance to older Americans was estimated at a minimum of $45 billion. Clearly, “business as usual” will not work for healthcare systems. There is a pressing need to invent a different way of caring for a rapidly growing population of older adults while reducing already unsustainable healthcare costs. Given the high cost of institutional care, helping older people to live independent lives in their own home must be a priority for healthcare systems. Andy Grove, former CEO of Intel, in an interview in Fortune described the health care situation as follows: “Healthcare is the largest segment of the economy in the U.S., and ... it is becoming too expensive to deliver. We’re still living in the ‘mainframe’ era of healthcare.... We can’t, as a society, afford to devote any more of our economy to it.... What we need is ... the healthcare equivalent of the low-cost PC” [5].

1.4

The Potential of Technology Substantial effort is being made to deploy IT and other technologies into the clinical environment, particularly the hospital arena. Much of the current focus is on administrative technologies (patient record management systems, information integration systems, etc.), and high-tech hospital equipment. Deployment of technology in support of at-home care has the potential to radically reduce the pressure on hospital resources but remains a significant challenge, because many of the required technology solutions do not yet exist or are in early prototyping stages. Athome care can potentially provide many advantages in terms of financial benefits, improved quality of life for patients, and more effective detection prevention or monitoring of many long-term chronic diseases. Figure 1.4 highlights the costs benefits of pushing healthcare back into the home environment where feasible. Medical devices, information technology, and communications have started to converge; this has the potential to revolutionize healthcare in the home. Advances in technology will make it possible for people to play a greater role in maintaining and monitoring their own health [6, 7]. At-home healthcare can help address the social and financial burdens of an aging population. At the same time the technology can support the network of caregivers such as family members, neighbors, and friends with new and innovative ways to monitor the wellbeing of older people, increase the levels of communication with the older person and to enable rapid response to emergency situations. The new social reality is that many of the family members will be geographically located away from an elderly relative yet there is compelling need for them to play an active part in the caregiving duties to an elderly parent or relative. Technological advances will result in time savings and travel overheads for the care givers. Home-care systems will enable people to monitor themselves with devices that give proactive warnings of illness so that they can turn to their doctors earlier, when intervention can be the most effective. For doctors, it will mean more

6

Healthcare and the Wireless Sensor Network

Figure 1.4

Delivery costs of healthcare (Intel).

efficient and effective healthcare, driven by patients who take greater responsibility for their own health. William Herman, director of the division of physical sciences in the Food and Drug Administration’s Center for Devices and Radiological Health (CDRH), which regulates medical devices in the United States, calls home-care systems “the fastest growing segment of the medical device industry” [8]. The at-home healthcare model is not designed to replace the traditional acute care role of hospitals, health centers and clinicians; instead, it includes the older person as an active participant in their own healthcare, particularly in the routine maintenance and monitoring of health. As Figure 1.5 shows, the home must become an equally important location for healthcare innovation as the hospital. 1.4.1

Sensor Networks for At-Home Care

Any at-home healthcare solution must detect and respond to the activities and/or characteristics of the older person. A network of sensors (worn, carried, and/or environmental) is an ideal technology platform for detecting and responding to health-relevant parameters such as movement, breathing, ECG, and social activity. Sensors, strategically placed on the human body, create a wireless body area network (BAN) that can monitor various vital signs while providing real-time feedback to the user and medical personnel. Further, wireless sensors can be deployed in a patient’s home environment to provide real-time and extended monitoring of activity and wellbeing. When coupled with communications technologies such as

1.4 The Potential of Technology

7

Technologies promoting personal health and wellness activities

Technologies supporting informal family and friends care network

Technologies for telemedicince—remote diagnostics and virtual physician visits

Figure 1.5 The home as a key location in the healthcare chain. Home health technologies should enable healthcare consumers and their informal and professional caregivers to work together to ensure the best quality of life. (Source: Intel.)

mobile phones and the Internet, the sensor network can keep family, caregivers and doctors informed, while also establishing trends and detecting variations in health. Appropriate technology design can minimize intrusion and protect privacy, maximize user friendliness and encourage long-term adherence to medical regimens. In some cases the WSN requires no direct patient interaction (this is ideal where the patient may be suffering from some level of cognitive decline). Because they are deployed where the patient spends most time, WSNs can deliver long-term datasets to assist in diagnostics and patient response to interventions. The data collected by a WSN can be stored and integrated into a comprehensive health record of each patient, which will allow identification of subtle changes in a person’s health. For example, changes in gait might indicate the onset of Parkinson’s in advance of visible symptoms [9]. Other example applications include medicine reminders, social connectivity, and emergency communications. 1.4.2

Wireless Biomedical Sensor Networks

The application of WSNs to health has attracted a significant amount of interest [10, 11]. When applied to biomedical applications they are often referred to as wireless biomedical sensor networks (WBSNs) [12]. WBSNs have a number of requirements that differentiate them from standard WSNs and WLANs. Table 1.1 outlines the key characteristics. The key features of WBSNs for medical applications identified by Hongliang et al. are as follows [13]: • • • •

Reliability; Biocompatibility; Portability; Privacy and security;

8

Healthcare and the Wireless Sensor Network Table 1.1

Comparison of the Features of WLAN, WSN, and WBSN Traditional Networks

Typical WSN

WSBN

Instance

WLAN

Smart Dust

Smart Ward

Coverage

50M

10M

1M

Density

Sparse

Dense

Dense

Data-centric

Address-centric

Data-centric

Data-centric

Large scale

N

Y

Y

Workloads

Unpredictable

Unpredictable

Partially predictable

Error rates

Medium

High

Must be very low

Energy constraint

No

Yes

Yes

Hops

Single

Multihop

Optional

Infrastructure

Y

N

N

Node failure

N

Y

Prohibited

Deployment

Random

Random

Planned

Source: [13].

• • • • •

Light weight protocols; Retrievability; Energy aware communication; Prioritized traffic; RF radiation safety.

WBSNs have been used to measure and process a wide range of health-relevant values, including electrocardiogram (ECG) [14], physical rehabilitation [11], pulse, blood oxygen saturation, respiration, skin temperature, blood pressure, and CO2 [15]. Because of their low-impact characteristics, WSNs are ideal for implementing at-home healthcare solutions. 1.4.3

Value to Clinicians and Caregivers

Assisted living technologies not only benefit the elder but also the clinicians and caregivers. For caregivers, technologies such as automatic monitoring systems will free them from 24/7 physical monitoring, enhancing their own quality of life. WBSNs can detect small changes in vital signals (e.g., heart rate and blood-oxygen levels) that are not obvious in a one-off visit to a doctor. Further, they address the issues associated with so-called “white coat syndrome”—skewed physiological and cognitive tests due to the stress and anxiety associated with a clinical visit. Measurements can be made unobtrusively over an extended period in a supportive home environment that more accurately reflect the true values for a given parameter. 1.4.4

Benefits of At-Home WSNs

As well as offering excellent long-term care benefits, the always-on nature of WSNs means that they can detect and respond to health crises in a timely manner. In particular, they can provide notice of significant shifts in key physiological parame-

1.5 General Approach to WSN in Healthcare

9

ters and may save lives, or initiate preventative care in order to prevent a health crisis. The potential value of WSNs for healthcare has not yet been fully explored. A significant research effort will be required to mine the vast data sets collected by WSNs and to find patterns that reveal information of interest to the healthcare professional. Breakthroughs in this area may support semiautomated analysis, diagnosis, and treatment processes in the future. Doctors will be assisted by an electronic counterpart, and patients’ health will benefit as a result of faster diagnosis and treatment of diseases. Other quality-of-life issues, such as privacy, dignity, and convenience, are supported and enhanced by the ability to unobtrusively provide services in the patient’s own home [16].

1.5

General Approach to WSN in Healthcare In this section we present an overview of the key principles and general methodology used by the authors in the deployment of wireless sensor networks (WSNs) in the solution of healthcare problems. 1.5.1

Key Principles

The following key principles should be kept in mind throughout the process: •

•

• •

•

This is a healthcare problem, not a technology problem. At the center is the patient, not the technology. There is often more than one way to achieve a clinical or care objective—the first technology solution that appears may not be the best. The simpler the technology, the better. WSNs for healthcare are mission-critical; reliability is of paramount importance. It has to work in the home, not just in the lab.

1.5.2

Methodology

The following methodology is valid for any WSN in healthcare: 1.

2.

Understand the problem. A clinician may already have analyzed the problem, and have come up with a technology outline for the engineer to develop. However, further analysis may pay dividends. At-home healthcare means that the appropriate environment to formulate any technology solution is not the clinic or the laboratory, but the home. Ethnographic observation of user behavior, where an understanding of how people live and why they live as they do, their constraints and their priorities day to day, can be very beneficial and has informed many of the solutions in which the authors are involved. Understand the end user. Who will use the solution in the longer term? What are their constraints or priorities? How do they feel about the type of

10

Healthcare and the Wireless Sensor Network

3.

solution envisaged? Usage modeling, where multidisciplinary teams use personas to explore the user experience from several perspectives, can be useful here. Understand what data must be collected. In order to test a clinical hypothesis or to achieve a care objective, some information about the activity or health state of the patient must be collected. It is important that a clear understanding of what data will be collected by the sensor network is shared by the clinician and the engineer, from the start. The information that the clinician needs is important, not the data that the sensor has the technological capability to collect. Focus on what is needed, rather than on what the technology allows.

4.

Understand the environment. Many WSN deployments do not achieve their objectives because they failed to take into account the differences between the laboratory/clinical environment and the home environment. Building methods and materials vary from location to location; these may impact on the technology. Other equipment in the home may interfere with the sensor technology.

5.

Consider sensor location. Are sensors to be worn, to be held, to be embedded in walls, floors, beds, or furniture? Keep in mind that the sensor network must be as unobtrusive as possible—solutions that require the patient to change his or her day-to-day behavior or which impact on comfort, privacy, or dignity are unlikely to be successful on a long-term basis. Almost all at-home solutions aim to be long-term.

6.

Select sensors and actuators. Take into account the data, the environment, and the placement. What impacts have these on power consumption, size and weight, form factor, radio communications, antenna type, and computational capability? Where at all possible, use components which are available off the shelf, avoiding experimental or prototype technology. Remember this is a healthcare problem, not a technology research project. Aim for a low-cost, light-touch solution.

7.

Specify and build the aggregator. The aggregator receives data from all the sensors in the network, and may transmit it to an analysis engine or data visualization system. Alternatively, it may itself process the data and trigger responses by actuators or by communications with caregivers, doctors, and so forth. Commonly, actuators take the form of local PCs or mobile devices such as PDAs and smartphones. Aggregator design is not covered in any detail in this book, because they typically use mass-market devices such as phones and PCs. Identify and deploy analysis and visualization capability. Ensure that the technology is in place to convert the data from the WSN into clinical information, and to allow the clinician to access this information in an appropriate manner. This may be out of the scope of a purely sensor-network project, but it is important that in such a case the precise nature of the interface between the network and the back-end data

8.

1.6 Conclusion

11

analysis/clinician system is clearly defined. The technology used for visualization is not explored in any detail in this book; analysis and visualization techniques and technologies are quite standard across many application domains. 9. Build the solution in the laboratory and verify that all elements work as planned. Discuss with clinicians and end users. 10. Build the solution in a friendly environment, such as in the home of an older person who has agreed to act as tester. 11. Deploy the solution in the “real world.” Continue to engage with end users to detect and correct any issues that may lead to failure to use the solution as planned. This methodology is explored in more detail in the following chapters, where it is also illustrated in three major case studies.

1.6

Conclusion This chapter has set the scene in terms of the problem domain—globally, a substantial demographic shift is increasing the average age and increasing pressure on healthcare systems. The potential value of technology has been highlighted, with a specific focus on wireless sensor networks. An overall approach to the design and build of wireless sensor solutions in healthcare has been outlined. The next chapter reviews the state of the art in wireless sensor technologies (hardware, firmware, and software).

References [1] [2] [3]

[4] [5] [6] [7] [8]

Cohen, J. E., “Human Population: The Next Half Century,” Science, Nov. 14, 2003, pp. 1172–1175. Hooyman, N. R., and Kiyak, H. A., Social Gerontology: A Multidisciplinary Perspective, 6th Ed., Allyn and Bacon, 2002. International Institute for Applied Systems Analysis, “Chart Demography: Population Aging in Europe,” Available: http://www.iiasa.ac.at/Research/ERD/DB/data/hum/dem/ dem_2.htm, (accessed: August 20, 2005; last update: 2002). Takamura, J., and B. Williams, “Informal Caregiving: Compassion in Action,” Informal Report, U.S. Dept. Health and Human Services, 1997. Schlender, B., “Intel Andy Grove: The Next Battles in Tech,” Fortune, May 12, 2003, pp. 80–81. Herman, W. A, “The Last Word: Health Technology Is Coming Home—and How!,” FDA Consumer, May, 2001. Dishman, E., “Inventing Wellness Systems for Aging in Place,” Computer, Vol. 37, No. 5, May 2004. Lewis, C., “Emerging Trends in Medical Device Technology: Home Is Where the Heart Monitor Is,” available: http://www.nursezone.com/Nursing-News-Events/devices-andtechnology/Emerging-Trends-in-Medical-Device-Technolgy-Home-is-Where-the-HeartMonitor-is_24198.aspx, (accessed: August 18, 2009: last update June 26, 2001).

12

Healthcare and the Wireless Sensor Network [9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

Patel, S., Lorincz, K., Hughes, R., Huggins, N., Growdon J. H., & Welsh, M., “Analysis of Feature Space for Monitoring Persons with Parkinson’s Disease With Application to a Wireless Wearable Sensor System,” Proceedings of the 29th Annual International Conference of the IEEE EMBS, 2007, pp. 6290–6293. Jovanov, E., “Wireless Technology and System Integration in Body Area Networks for m Health Applications,” Proceedings of the 27th Annual International Conference of the IEEE Engineering in Medicine and Biology Society, Shanghai, China, September 2005. Jovanov, E., Milenkovic, A., Otto C. and de Groen, P., “A wireless body area network of intelligent motion sensors for computer assisted physical rehabilitation,” Journal of NeuroEngineering and Rehabilitation, 2005, vol 2, no. 6, 2005. Chen, X., Meng, M. Q.-H and Hongliang, R., “Design of Sensor Node Platform for Wireless Biomedical Sensor Networks,” Proceedings of the IEEE Engineering in Medicine and Biology 27th Annual Conference, September 2005. Hongliang R, Meng, M. Q.-H. and Chen, X., “Physiological Information Acquisition through Wireless Biomedical Sensor Networks,” Proceedings of the IEEE International Conference on Information Acquisition, June 27–July 3, 2005, Hong Kong and Macau, China, pp. 483–488. Penders, J. Gyselinckx, B. Vullers, R. De Nil, M., Nimmala, V., van de Molengraft, J., Yazicioglu, F., Torfs, T., Leonov, V., Merken, P., and Van Hoof, C., “Human++: From technology to emerging health monitoring concepts,” Medical Devices and Biosensors, 2008, ISSS-MDBS 2008, 5th International Summer School and Symposium on, 2008, pp. 94–98. Lymberis, A., “Smart Wearables for Remote Health Monitoring, From Prevention to Rehabilitation: Current R&D, Future Challenges,” Proceedings of the 4th Annual IEEE Conference on Information Technology Applications in Biomedicine, April 2003, pp. 272–275. Stankovic, J. A., Cao, Q. Doan, T., Fang, L., He, Z., Kiran, R., Lin, S., Son, S., Stoleru R. and Wood, A., “Wireless Sensor Networks for In-Home Healthcare: Potential and Challenges,” Workshop on High Confidence Medical Devices Software and Systems (HCMDSS), 2005.

CHAPTER 2

Sensor Network Technologies 2.1

Introduction This chapter reviews the state of the art in wireless sensors and related technologies. The chapter describes the various ingredients available to the engineer in designing a wireless sensor network (microprocessors, radios, different types of sensor, operating systems, etc.). Particular attention is paid to antennas, a frequent point of failure in WSN solutions. Having completed this chapter, the reader will be equipped with the requisite technology background to engage in requirements capture and project design.

2.2

Wireless Sensor Networks In a wireless sensor network, dozens, hundreds, or even thousands of tiny, battery-powered computing devices are scattered throughout a physical environment. Each device is capable of monitoring—sensing—and/or displaying—actuating— information. Sensing may include the collection of values for temperature, humidity, vibration, electrocardiogram, pulse, or other health-relevant data. An actuating device may cause an LED to blink, turn on lights, change colors on a display, display textual information, or any trigger other action that prompts a response or informs a human. WSNs are used in commercial, industrial, environmental, and healthcare applications to monitor data that would be difficult or expensive to capture using wired sensors. A variety of applications have been presented in the literature for wireless sensor networks. These include aircraft monitoring [1], ecological habit monitoring [2], smart spaces [3], education [4], and geological monitoring [5, 6]. When applied to biomedical type applications they are often referred to as wireless biomedical sensor networks (WBSNs) [7], which have a number of characteristics that differentiate them from standard WSNs and WLANs. Table 2.1 outlines the key characteristics. A WSN device is a packaged data collecting or actuating component, which includes a sensor and/or an actuator, a radio stack, an enclosure, an embedded processor, and a power delivery mechanism. Depending on the device, it may also include an antenna. Devices are held within an enclosure. A transceiver module is a class of device that is not packaged within an enclosure. A transceiver module usually combines an embedded processor, radio stack,

13

14

Sensor Network Technologies Table 2.1

Comparison of the Features of WLAN, WSN, and WBSN Traditional Networks

Typical WSN

WSBN

Instance

WLAN

Smart Dust

Smart Ward

Coverage

50M

10M

1M

Density

Sparse

Dense

Dense

Data-centric

Address-centric

Data-centric

Data-centric

Large scale

N

Y

Y

Workloads

Unpredictable

Unpredictable

Partially predictable

Error rates

Medium

High

Must be very low

Energy constraint

No

Yes

Yes

Hops

Single

Multihop

Optional

Infrastructure

Yes

No

N

Node failure

No

Yes

Prohibited

Deployment

Random

Random

Planned

Source: [7].

antenna, and sometimes sensor and actuators, usually not packaged in an enclosure. Motes and the SHIMMER baseboard are two examples of transceiver modules. A sensor or actuator module combines the sensing and I/O on a plug-in board for the transceiver module described above. The SHIMMER ECG board is an example. By combining a transceiver module, a sensor module, an enclosure, and a battery, one would get a WSN device. A sensor is the small piece of technology that actually interacts with the environment and which sends an appropriate signal to the embedded processor (microcontroller unit). Thus, for example, a temperature sensor will note the temperature, and send a signal to the embedded processor. Depending on the design and the choice of technologies, the sensor may be within the same transceiver module as the processor, or it may be a plug-in addition to the transceiver module. The microcontroller unit (MCU) may decide to forward the sensed signal to an aggregator, or to do some processing, sleep for a while, or wait until the next cycle to forward the information from the sensor. When ready, the MCU sends the signal to the radio stack; the radio stack then uses a communications protocol (e.g., IEEE 802.15.4), and a transport protocol (e.g., ZigBee) with a data protocol (Continua or IEEE 11073) to pass the information to an aggregator (PC or cellular phone). The aggregator must, of course, have a compatible radio stack. The data is sent out of the radio stack to an antenna and thereby received by another antenna. The communication protocol layers transmit on a given frequency and format; for example, a 2.4-GHz FM transmission, using a 1-MHz-wide spread spectrum in the case of IEE 802.15.4. 2.2.1

Network Architectures

All WSNs use sensors to collect data and then aggregate this data for analysis and subsequent use. In the healthcare context, aggregated data may be transmitted to a clinician or may prompt an actuator to respond to the patient.

2.2 Wireless Sensor Networks

15

While they share this commonality of function, wireless sensor network solutions may utilize a range of different network architectures. The ultimate goal of collecting sensed data at an aggregation point can be achieved by autonomous ad hoc networking, by star networking, or by classical end-to-end network configurations. In an ad hoc network, a large number of devices are broken down into clusters, within which the devices act as data relays with dynamic traffic routing; as a result of this arrangement, ad hoc networks are tolerant of individual device failures. Data travels to neighboring devices and eventually passes through an aggregator in the cluster to a target location, where it can be processed (see Figure 2.1). In a star configuration the devices communicate directly with either a repeater hub or a data aggregator without communicating with each other.

Data processing host Aggregated data transmission Controller module

Mote

Mote Figure 2.1

Illustration of an ad hoc sensor network.

16

Sensor Network Technologies

When the data collected from all the devices (see Figure 2.1) is aggregated on a particular device, this device may either process the data locally or relay it to backend infrastructure. 2.2.2

TCP/IP and WSNs

In recent years, implementations of the TCP/IP network stack have appeared on WSN devices, devices to be connected directly into the Internet. This means that data can travel directly from its source—the sensor—to its ultimate destination in what is, in the application layer, a single step. This capability opens a range of new possibilities for WSNs, including the provision of a platform for higher-level communications protocols such as Telnet, SIP, HTTP, IMAP, NTP, and DHCP. An access point is necessary to support TCP/IP-enabled WSNs; implementations of 6LOWPAN, the IPv6 protocol over 802.15.4 will combine the cluster advantages of an ad hoc network with the autoconfiguration of IPv6, bundling the entire WSN into the global IP network in the presence of reach-back provided by a bridge or router.

2.3

WSN Technologies In a sensor network, dozens, hundreds, or even thousands of tiny, battery-powered computing devices are scattered throughout a physical environment. In a WSN, each device is capable of monitoring—sensing—and/or displaying—actuating— information. Sensing may include data collection, such as temperature, humidity, vibration, electrocardiogram, pulse, gait information, or other health- related parameters. An actuating device may cause an LED to blink, turn on lights, change colors on a display, display textual information, or any other action that prompts a response or informs a human. A WSN device is a node in a wireless sensor network that is capable of gathering sensory information, processing it in some manner, and communicating with other nodes in the network. The majority of wireless sensor platforms share a common set of system components: • • • •

• •

Microcontroller: provides the computational capabilities to the platform; Radio transceiver: provides low-power wireless communications; Sensor interfaces: hardware interfaces to external sensors; Actuator interfaces: provide human interaction interface (LED, displays, etc.); Antenna; Power: through batteries, capacitors, or solar arrays.

Often these devices for business or engineering reason are broken down into modules. These modules are themselves broken into a sensing or display module and a transceiver module. Transceiver modules are convenient in a design because they provide a common radio stack and embedded processor for a cluster of differ-

2.3 WSN Technologies

17

General Device Architecture (What’s in a Node?) A general WSN device architecture consists of an embedded processor, some memory, a radio stack (transmitter or transceiver), and a communication bus to sensors or actuators. A typical depiction of a generalized WSN device is shown in Figure 2.2. As shown in the figure the embedded processor communicates with the sensor or actuator through the use of communication bus protocols. A simple example of a WSN device is the X10 motion detector. These motion detectors are commercially available for security related applications. These devices are typically arranged in a star network configuration, where each device communicates with a central data aggregator (the security panel). By opening the housing of the motion sensor one can easily identify the generalized architecture of the WSN device (see Figure 2.3). In the picture of the device one can easily see the pyroelectric sensor in the center that is made of a crystalline material that generates a surface electric charge when exposed to heat in the form of infrared radiation. A filter window limits incoming radiation to the 8- to 14-μm spectrum, which is most sensitive to human body radiation. Next to the sensor is the radio transmitter. Below the sensor is an embedded processor. Power in this device comes from two AAA batteries. In comparing the generalized WSN device architecture to many existing devices one can easily recognize the various components in the design and their function.

Sensing or Actuating Device Or Communication PORT (wired)

Or another RF device

UAR T

I2C

ADC

G P IO

Sensing Sensingor or Actuating Actuating Device (e.g. BP, heartbeat, magnetic switch, etc) etc.)

Low Power Embedded Processor Small Amount of Code and Data Memory

RF

SPI SPI

Radio -Stack Usually SiP chip or discrete stack (Sometime SoC with embedded processor)

e.g. Mote, PICZ,iMote, iMote Z-wave,ZigBee, X10,GE security, or Bluetooth

Figure 2.2

Schematic of the WSN device architecture.

18

Sensor Network Technologies

Actuator Radio Transmitter

Sensor

Processor

Figure 2.3

X10 motion detector.

ent WSN devices. Common examples of transceiver devices include the WINS (Rockwell) [8], Mica/Mica2/Mica2DOT (Berkeley/XBOW), [9, 10] the GNOMES (Rice) [11], BTNode (ETH Zurich) [12], and the MANTIS Nymph (Colorado) [13]. These transceiver modules often will have sensing or actuators on them like the LEDs on the Crossbow Mica2 or the temperature sensors on the Berkley Telos Mote. An example of another transceiver module is the SHIMMER platform, which is examined in detail later in this book. Many of the commercial devices have an operating/development environment such as TinyOS, but few have the resources to run a true multithreaded operating system. WSN devices also have some memory (often an SD card) and a power supply (commonly a Li-ion battery). Modules may or may not have an antenna built onto the device, depending on design constraints. Correct antenna design, and configuration are important for data reliability and integrity—crucial characteristics for WSNs in healthcare applications. Using a common transceiver module for a device design allows easy reconfiguration and reuse during the design process; this in turn enables rapid development. As the design cycle matures, the cost of the modules in high volume manufacturing may warrant the integration of the module and the sensor board into a single printed circuit board design. The following are important examples of integrated modules and sensors. 2.3.1

Motes

Mote technology was developed by Intel in collaboration with the UC Berkeley-based Center for Information Technology Research in the Interest of Society (CITRIS) in the late 1990s. It was later sold commercially by Crossbow Inc. and Moteiv. Being one of the earliest wireless sensor platforms, it became one the best recognized platforms, with many research adoptions. The mote hardware platform consists of a microprocessor and radio chip (MPR). Sensors connect directly to the

2.3 WSN Technologies

19

mote processor radio boards via various interfaces. This combination gives the mote the ability to sense, compute, and communicate. The microprocessor collects the data in a digital format that comes from a broad array of sensory inputs, and the radio enables the mote to wirelessly transmit its readings throughout its network. Preprocessing by the mote enables the raw data collected by the sensors to be analyzed in various ways before it reaches an aggregator or repository, ensuring a high-density stream of information that can be acted upon in real time. Standard AA or coin-style lithium-ion batteries keep motes “alive” for timescales ranging from months to years. Although the size, type, and configuration of motes in a sensor network depend largely on the application, common design constraints include power conservation, compact form factor, and limited memory and storage capacity. The first mote was the WeC [14, 15], which appeared in 1998 and featured an AT90LS8535 MCU and TR100 transceiver. This was followed in the next year by the René mote, which had a similar hardware configuration. The year 2000 brought the introduction of the ATmega163 CPU, which was featured in the René 2 [16] and Dot motes [17], providing a 100% increase in both program memory and RAM. The wakeup time also significantly improved from 1,000 to 36 μs. Based on field trials of this platform, a second-generation platform called MICA was developed; it appeared in 2001 (Figure 2.4). The MICA name was derived from its close resemblance to the layered structure of the mineral mica [18]. 2.3.2

MICA

The MICA mote is comprised of a series of thin processor/radio and sensor circuit cards sandwiched together to form an integrated wireless smart sensor. The MICA

Figure 2.4

Evolution of CPUs in mote base stations.

20

Sensor Network Technologies

motes feature an Atmel ATmega128L MCU with 128 KB of program memory and 4 KB of RAM. The MICA module has three sleep modes: idle, in which the processor is off; power down, which shuts everything off except the watch-dog timer; and power save, which is similar to power-down, but leaves an asynchronous timer running. Power is provided by any 3V power source, typically AA batteries or lithium-ion batteries. The third generation of motes were named MICA2 (2002), and featured improved microprocessors (Atmel AVR) and a better radio (a CC1000 operating at 433, 868/916, or 310 MHz) than the previous MICA1 generation. They had a 1-year lifespan using two AAA batteries. MICAz [19, 20] (based on Atmel AVR and the CC2420) was the next generation 2.4GHz platform, featuring IEEE 802.15.4/ZigBee compliance and several new capabilities that enhance its functionality. The most recent significant step in commercial mote development was the Telos [16] in 2004. It features an MSP430 MCU, a CC2420 radio, and a USB interface for direct connection to a USB port on host PC. Both data collection and programming can be performed via a USB port. The Telos is sold commercially by Crossbow and Moteiv. 2.3.3

iMote

Another mote in a higher functionality class from the micropower platforms described above was the Intel iMote [21], which initially appeared in 2003. This mote, like the AWAIRS [71] StrongARM-based sensor developed at UCLA in 1998, had instead of a very low-power 8- or 16-bit MCU and ARM7 32-bit processor with, relatively speaking, an abundance of RAM and flash memory. The iMote also had a Bluetooth radio, and an expansion connector that allowed for the expansion of functionality through the addition of daughter cards. Its 2006 follow-on, the iMote2 [22], has the extrapolation of the ARM processor family, the Xscale processor, which runs Linux quite comfortably. While this platform consumes a great deal more energy than the Telos or MICAz mote—one to two orders of magnitude higher—its larger memory space (32 megabytes of flash and RAM) and carriergrade, multithreaded operating system set it apart from other tiny, embedded sensors. The iMote2 has a CC2420 802.15.4 radio on board, and a similar expansion-card layout to the iMote. An overview of the available modules, including microprocessor and radio choices, is provided in Table 2.2. 2.3.4

Microcontrollers

The heart of any wireless sensor node is its microcontroller unit (MCU), which provides the computational capability to the sensor. It differs from standard central processing units (CPUs) in its focus on self-sufficiency, power efficiency, and low cost. Many embedded processors exist on the market, (e.g., as seen in the example of the X10 motion detector, a microchip PIC processor was used). In many of the WSN devices used for healthcare, two types of MCU are common, the Atmel ATMEG family [23] and the Texas Instruments MSP family [24] for MCUs. These are commonly selected because of their ability to go into programmed sleep cycles thereby reducing their power needs.

2.3 WSN Technologies

Table 2.2

21

A Survey of Wireless Sensor Nodes

Sensor Name

Microcontroller

Radio

Ant

MSP430F1232

AquisGrain

RAM/ EEPROM/ FLASH

OS

Year

Organization

Nordic nRF2401 256 B/256 B/8 KB

Ant

2005

Dynastream Innovation Inc.

ATMega128

CC2420 radio

4 KB/4 KB/128 KB

-

2004

Philips Research

AWAIRS 1

StrongARM SA1100

Conexant RDSS9M

4 MB/ /4 MB

TinyOS

1998

UCLA/ Rockwell

BEAN

MSP430F169

CC1000

2 KB/256B/60 KB

YANTOS

2004

Federal University of Minas

BSN

MSP430

Chipcon CC2420

2 KB/256 B/60 KB

TinyOS

2004

Imperial College

BTNode

ATmega128L

Ericsson ROK 101 007

4 KB/4 KB/128 KB

TinyOS

2001

ETH

CITNode

PIC16F877

Nordic nRF903

368B/ /8 KB

TinyOS

2004

Cork Institute of Technology

COTS Dust Family

AT90LS8535

RF Monolithics TR1000

512B/512B/8 KB

TinyOS

1999

UC Berkeley

DOT

ATmega163

TR1000

1024 B/512 B/16 KB TinyOS

2000

UC Berkeley

DSYS25

Atmega128L

Nordic nRF2401 4 KB/4 KB/128 KB

TinyOS

2004

University College Cork

Ember

ATmega128L

Ember 250/260

4 KB/4 KB/128 KB

EmberNET 2005

Ember

EnOcean

Microchip PIC18F452

Infineon TDA5250

1.5K/32K/16K

TinyOS

2005

EnOcean GmbH

EyesIFX 1/2

MSP430F149 MSP430F1611

Infineon TDA5250

Controllerdependent

TinyOS

2004 2005

TU Berlin

FireFly

ATmega32L

Chipcon CC2420

2 KB/1 KB/32 KB (ROM)

Nano-RK

2006

Carnegie Mellon University

Fleck

Atmega128L

Nordic nRF903

4 KB/4 KB/128 KB

TinyOS

2005

CSIRO

GNOMES

MPS430F149

National Semiconductor LMX9820

2 KB/512 B/60 KB

GNOMES 2002 OS

Rice University

IBadge

ATmega 103L

TR1000

4 KB/4 KB/128 KB

PALOS

2002

UCLA

iMote 1

ARM7 Core

Zeevo TC2001

64 KB/1024 B/512 KB

TinyOS

2003

Intel

22

Sensor Network Technologies

Table 2.2 (continued)

Radio

RAM/ EEPROM/ FLASH

OS

Year

Organization

Intel PXA 271

CC2420

32 MB/ /32 MB

TinyOS

2005

Intel

KMOTE

MSP430

Chipcon CC2420

2 KB/512 KB/60 KB TinyOS

2007

Indian Institute of Technology

MEDUSA MK-2

ATmega128L AT1FR4081 ARM THUMB

TR1000

Controllerdependent

PALOS μCos-II.

2001

UCLA

MICA

ATmega103

TR1000

4 KB/4 KB/128 KB

TinyOS

2001

Crossbow

MICA2Dot

ATmega128L

Chipcon CC1000

4 KB/512 KB/512 KB

TinyOS

2002

Crossbow

MICAz

ATmega128L

Chipcon CC2420

4 KB/512 KB/512 KB

TinyOS 2002 SOS MantisOS

Crossbow

MICA 2

ATmega128L

Chipcon CC1000

4 KB/512 KB/512 KB

TinyOS

2002

UC Berkeley/ Crossbow

MITes

nRF24E1 (8051 CORE)

nRF24E1

4 KB/4 KB/

n/a

2006

MIT

Mulle

Renesas M16C/62

20 KB/256 KB/256 Mitsumi WML-C10AHR KB

TinyTimber

2005

Luleå University of Technology

Nymph

ATmega128L

CC1000

4 KB/4 KB/128 KB

MANTIS

2003

University of Colorado

uPart

Microchips rfPIC16F675

Microchips

64 B/128 B/1.4 KB

UPart Logger

2005

Teco/ University of Karlsruhe

PicoNode

StrongARM SA-1100

Proxim RangeLAN

4 MB/ /4 MB

n/a

2002

UC Berkeley

Pluto

MSP430F149

ChipCon CC2420

10 KB/256 B/48 KB

TinyOS

2004

Harvard

ProSpeckz

AtmelAT91 (ARM7TDMI core)

Chipcon CC2420

8 KB/ /2 MB

Specknet

2004

University of Edinburgh

René

ATmel 90LS8535 TR1000

512B/32 KB/8 KB

TinyOS

1999

UC Berkeley

René 2

ATmega163

1024B/512B/16 KB

TinyOS

2000

UC Berkeley

RFRAIN

Chipcon CC1010 CC1010 (8051)

2 KB/ /32 KB

RFRAIN libraries

2003

MIT

Sensor Name

Microcontroller

iMote 2

RFPIC12F675

TR1000

2.3 WSN Technologies

23

Table 2.2 (continued) RAM/ EEPROM/ FLASH

OS

Year

Organization

Chipcon CC1010 CC1010 Renesas M16C/28

2 KB/ /32 KB

TinyOS

2005

University of California

PIC18F452

CDC-TR-02B

1.5K/32K/16K

Pavenet

2003

The University of Tokyo

ScatterWeb/E MSP430F149

TR1000

Controllerdependent

Contiki

2004

FU Berlin/ ScatterNet

SB

MSP430F1612

Chipcon CC1020

Sensinode

MSP430

Chipcon CC2420

10 KB/1024B/256 KB

FreeRTOS, 2005 NanoStack TinyOS

Sensinode Ltd

SHIMMER

MSP430F1611

WML-C46A Chipcon CC2420

10 KB/256B/48 KB

TinyOS

2004

Intel

Smart-its

ATmega103L PIC16F876 PIC16F877

Ericsson BT RF Monolithics TR1000

4 KB/4 KB/128 KB 368B/256B/

Smart-Its

2001

Lancaster University/ University of Karlsruhe

Spec

AVR like RISC core

FSK Transmitter 3 KB

-

2003

UC Berekely

SpotON

Dragonball EZ

RF Monolithics TR1000

2M/2M

-

1999

Intel

SquidBee

ATmega168

XBee PRO

1 KB/512 B/16 KB

Firmata

2006

University of Zaragoza/ Libelium

SunSPOT

ARM7 Core CC2420 StrongARM920T

256 KB/1024 B/2 MB 512 KB/1024 B/4 MB

Squawk

2005

Sun Microsystems

TELOS/ Tmote Sky/ SkyMOTE

TI MSP430F149 CC2420

10 KB/256 B/48 KB

TinyOS 2004 SOS MantisOS

Crossbow/ Motiv/UC Berkeley

TinyNode 584

MSP430

XE1205

10 KB/256 B/48 KB

TinyOS

2006

EPFL/ Shockfish

T-Nodes

ATmega128L

868 MHz FSK Transceiver

4 KB/512 KB/128 KB

SOWNet.

2006

SOWNet Technologies

TinyOS

2005

Tyndall Institute Cork

Sensor Name RISE

U

3

Microcontroller

Tyndall Mote ATmega128L

Radio

TinyOS

Nordic nRF2401 4 KB/512 KB/128 KB

24

Sensor Network Technologies

Table 2.2 (continued) Sensor Name

Microcontroller

Radio

RAM/ EEPROM/ FLASH

OS

Year

Organization

Tyndall Mote ATmega128L

Nordic nRF2401 4 KB/512 KB/128 KB

TinyOS

2005

Tyndall Institute Cork

WeBee

8051 Microcontroller

Chipcon CC2430/ CC2431

n/a

-

Lucerne University of Applied Sciences

WiseNet

Chipcon CClOlO Chipcon CCl0l0 2 KB/ /32 KB

TinyOS

2003

Bradley University

WINS

StrongARM SA-1100

Connexant RDSSS9M

1 MB/ /4 MB

eCOS RTOS

2002

Rockwell

XYZ

ML67 Series ARM/THUMB

Chipcon CC2420

32 KB/4 KB/256 KB SOS

2005

Yale

μAMPS

StrongARM SA-1100

National LMX3162

4 MB/ /4 MB

μOS

1999

MIT

128 B/4 KB/128 KB

Atmel’s MCUs are based on a Harvard architecture (programs and data stored separately) with a RISC instruction set. They have clock speeds up to 20 MHz with 20 MIPS. However, many applications run the MCUs at lower speeds in order to achieve lower power consumption. They also feature full integration onto a single die of the Flash, EEPROM, and SRAM. The architecture is optimized for high-level programming languages, especially C. Atmel MCUs have been successfully used on a wide on wireless sensor platforms including DSYS25 [25], MicaZ [19], BTNode [13], Nymph [26], and Tyndall Mote [27]. Atmel’s range of 32-bit RISC MCUs have also been utilized in sensors. The AT91 based which is based on the ARM7TDMI processor core was used by University of Edinburgh in the ProSpeckz sensor [42]. Texas Instrument’s MSP430 CPU family uses a von Neumann architecture (common memory space in which both program instructions and data are stored) with various memory and peripheral configurations. The MSP430 is designed specifically for ultralow-power applications, using a flexible clocking system and a wide variety of operating modes designed to reduce power consumption, thereby extending battery life. The current draw when in sleep/power-down mode is 0.1 μA, 0.8 μA in standby, and 250 μA in operating mode when running at 3V. The MSP430 can operate down to 1.8V, further improving a superior power specification. The MSP430 is used on the SHIMMER [28], Telos [16], BSN node [29], Tmote [30], and Ant sensors [31]. 2.3.5

Radio Transceivers

All wireless sensors require an on-board transceiver to support communications. A transceiver is typically defined as a combined transmitter and receiver, sharing common circuitry or a single housing. Table 2.3 shows the transceivers that are com-

2.3 WSN Technologies Table 2.3

25

Common Radio Choices for WSNs

CC1000

CC1010

CC2420

TR1000

XE1205

nRF2401

Manufacturer

Chipcon

Chipcon

Chipcon

RFM

Semtech

Nordic Semiconductor

Operating frequency (MHz)

315/433/ 868 /915

315/433/ 868/915

2400

916

433/868/915

2400

Bit rate (kbps)

76.8

76.8

250

115.2

1.2-152.3

1000

Power supply voltage (V)

2.1–3.6

2.7–3.6

2.1–3.6

2.2–3.7

2.4–3.6

1.9–3.6

monly used on wireless sensor platforms. From a functional perspective, they operate either at 315/433 and 868 MHz in Europe, 915 MHz in North America, or at 2.4 GHz worldwide. Many of the early wireless sensor platforms were based on the TR1000 transceiver, which offers data rates up to 115 Kbps based on amplitude-shift keying (ASK). Later platforms such as the MICA 2 were based on the Chipcon CC1000, which supports both ASK and frequency-shift keying (FSK). The ASK approach to data transmission has the advantage of being able to implement a lower current budget in comparison to FSK, thus reducing battery size and cost. However FSK exhibits superior noise immunity in comparison to ASK. More recently, the development of the 802.15.4 standard that is used by the ZigBee stack has driven the widespread utilization of the Chipcon CC2420 and Nordic Semiconductor nRF2401 in various platforms such as SHIMMER, TELOS, DSYS25, and Tyndall mote. 2.3.6

Radios for WSN Applications

Examining the subcomponents of the WSN device in greater detail begins with an understanding of the various radio options available. WSN devices can be provided with a variety of radio options, some of which are proprietary, (e.g., X10) while others are based on open standards (e.g., Bluetooth). For the purpose of this review, only technologies that have been accepted as standards will be discussed. Many of the WSN device radios operate in the industrial, scientific, or medical (ISM) bands. These are available worldwide and license-free. Since the ISM bands are open to all radio transmitters as long as they satisfy the regulations, interference immunity is an important issue. The sensor network radio domain can be broken into three segments, which are associated with range. The first of these three segments is the long-range communication. Communications in this segment require movement of small amounts of information across a long range, typically facilitated by an ad hoc architecture. The second of these segments sensors must communicate with high bandwidth and over medium ranges. An example is the transmission of data from body-implanted or body-wearable sensors through to the hospital; an ECG that transmits data directly to a cell phone is a typical application. The final segment in the sensor network domain includes shorter range low bandwidth sensors used for home-care monitoring. Table 2.4 shows the distances needed and the communication bandwidth needed for each segment. Long-range environmental communications may be

26

Sensor Network Technologies Table 2.4

Data Rates and Ranges for Various Sensor Systems

Segment

Range

Data Rate

Purpose

Long-range

>50 miles

>1 kbps

Long-range environment monitoring.

Near-range

>300m

>200 kbps

Monitoring various in vivo or wearable sensors.

Home

>100m

>1 kbps

Monitoring for home care.

done through GSM or GPRS systems. Near-range communications can be supported by 802.11 or Bluetooth, while short range or home communications can be provisioned by either Bluetooth or 802.15.4. In some cases the device can have two or more radios that can be selected depending on the specification application required. 2.3.6.1

Common Radio Choices for WSNs

Common radio choices for WSNs are profiled here. The characteristics of the various radio options are of course critical when selecting the right radio for a particular application (Table 2.5). 2.3.6.2

IEEE 802.15.4

IEEE 802.15.4 is part of the IEEE’s 802.15 wireless personal-area network specification activities. It uses a simple (28K-byte) packet-based radio protocol aimed at very low-cost, battery-operated sensors that can intercommunicate and send low-bandwidth data to a central receiving station. 802.15.4 is a specification of a low-power air interface, and the accompanying MAC protocol. It is optimized for short-range communications (typically 30–50 meters), low data throughput with a 30-ms network join time and supports flexible topologies, (i.e., star or ad hoc architectures). It also supports very large numbers of nodes—a single 802.15.4 network can accommodate up to 216 devices, which are assigned during the association procedure. It is designed to maximize energy efficiency at the physical and MAC layers. 802.15.4 is a CSMA/CA MAC-based system, with a total of 27 channels specified in the frequency bands of 2.4 GHz, 902 to 928 MHz, and 868.3 MHz. Three different over-the-air data rates can be allocated: 16 data channels with a data rate of 250 kb/s, 10 channels with a data rate of 40 kb/s and 1 channel with a data rate of 20 kb/s. Such a network can choose one of the 27 channels depending on availability, congestion state, and data rate of each channel.

Table 2.5

Common Radio Choices

Technology

Data Rate

Idle Current

Startup Time

802.15.4

250 Kbps

7 mA

Low

Bluetooth

1 Mbps

22 mA

Medium

802.11

11 Mbps

160 mA

High

UWB

100 Mbps

2 mA

Low

2.3 WSN Technologies

27

The duty cycle of communications in an 802.15.4 network is around 1%, resulting in very low average power consumption for static and dynamic environments. However, it is also up to higher protocol layers to observe the low duty cycle. Most power-saving mechanisms in 802.15.4 are based on beacon-enabled mode. The 802.15.4 standard defines only a limited number of primitives (only a third of the number used within Bluetooth, for example) and is therefore most suitable for simple devices with limited memory and computational capacity. Two different types of devices are defined: a full function device (FFD) and a reduced function device (RFD). An FFD can talk to RFDs and FFDs while an RFD can only talk to an FFD. The simple complexity, low-cost, low-power features of 802.15.4 are intended to enable broad deployment of wireless networks able to run for years on standard batteries, for a typical monitoring application [32]. 2.3.6.3

802.15.4/ZigBee

802.15.4/ZigBee is built on the IEEE 802.15.4 standard and specifies the MAC and PHY (physical) layers. “ZigBee” comes from higher-layer enhancements developed by a multivendor consortium called the ZigBee Alliance. For example, 802.15.4 specifies 128-bit AES encryption, while ZigBee also specifies how to handle encryption key exchange. 802.15.4/ZigBee networks are designed to run in the unlicensed frequencies, including the 2.4-GHz band in the United States. IEEE 802.15.4/ZigBee is intended for uses such as the control of lights, security alarms, motion sensors, thermostats and smoke detectors, and environmental monitoring. There are plans for ZigBee integration with residential network gateways that merge traffic onto a broadband Internet connection. ZigBee has specific advantages over other short-range protocols such as 802.11 and 802.15 for WSN applications; devices based on these latter protocols use too much power and the protocols are too complex (and thus more expensive) to be embedded in devices on very large scales [33, 34]. Unfortunately, the ZigBee Alliance has not yet made its protocol available as an open standard; additionally, it adds another protocol between the device and the global IP-based network. 2.3.6.4 TCP/IP

As mentioned earlier, the open-standard IP stack rests comfortably on top of 802.15.4, so this combination offers a high degree of application interoperability along with superior power characteristics, as well as the ability to provide cell-based mobility so that a network session will be maintained as the device moves. Research over the past few years in the area of WSNs has focused on the utility of this protocol, particularly for body sensor applications [35–37]. When implementing TCP/IP stacks on 802.15.4 devices each contains a small IPv4 protocol stack with TCP and UDP [38]. The embedded processor on each device implements a lightweight SIP-based streaming media server over UDP [39] and also runs a local Telnet server and a HTTP server for remote access and control. Aggregators with a 802.15.4 radio stack can then also easily integrate wired Ethernet and may function as a network coordinator if the larger network is out of service. When all the devices are connected through the larger internet over TCP/IP various devices then may have

28

Sensor Network Technologies

the ability to interface with the wireless device to configure it, maintain it, send or receive data or graphically display live content by connecting to the SIP-based streaming media servers. 2.3.6.5

Bluetooth

Bluetooth is a low-cost, low-power, robust, short-range wireless communication protocol. It was first developed as a cable replacement between mobile phones, headsets, PDAs, laptops, and so forth, but it has evolved to solve more general applications in the personal area network (PAN) domain. The Bluetooth stack is quite complex, giving it a rather large footprint, which means that it cannot be used in devices constrained in terms of processing-power and memory. A collection of devices communicating using Bluetooth is referred to as a piconet. Bluetooth operates in the license-free 2.4-GHz ISM band. It uses 79 1-MHz channels to transmit data. Interference between other ISM band devices (802.11 and 802.15.4 devices) and other Bluetooth piconets is minimized using frequency hopping spread spectrum (FHSS), where the carrier is rapidly switched (hops) among the 79 available channels. The frequency hopping sequence is controlled by the master device within the piconet. Other Bluetooth interference reduction techniques include adaptive power control, channel quality driven data rate (CQDDR), and adaptive frequency hopping (AFH). The Bluetooth core system consists of an RF transceiver, baseband, and protocol stack. The system is usually implemented partly in hardware and partly in software running on a microprocessor. The partitioning can be configured in different ways depending on the application, from solutions where the radio, protocol stack, and application runs on a single chip to solutions where there is a separate radio chip, a processor running the lower layers of the stack, and yet another processor running the upper layers of the stack and the application. Extensive documentation and analysis of Bluetooth and its applications can be accessed from the Bluetooth SIG’s Web site at www.bluetooth.org. 2.3.6.6

IEEE 802.11 (WiFi)

Wireless local area networks based on the IEEE802.11 series of standards can provide a high capacity link with reasonable latency for ranges up to 100 meters. They operate in unlicensed bands, and are therefore subject to interference. Later versions of the standard include a form of dynamic channel assignment to allow access points to shift frequency in the event of interference or jamming signal blocking the channel. Wireless LANs are suitable for connecting sensors with high bandwidth requirements (e.g., video sensors), and are also ideal as a traffic conduit from an aggregator to the wider Internet. However, high-power consumption makes 802.11 less suitable for use with small, low-power sensors. Higher component costs may also make 802.11 an inappropriate choice for many WSN deployments. 2.3.6.7

Ultrawide Band (UWB)

Impulse radio-based UWB technology has a number of inherent properties that are well suited to sensor network applications. In particular, impulse radio-based UWB

2.3 WSN Technologies

29

systems have potentially low complexity, low cost, and very good time domain resolution, which makes them very suitable for location-specific and tracking applications. The low complexity and low cost of impulse radio UWB systems arise from the essentially baseband nature of the signal transmission. Unlike conventional radio systems, the UWB transmitter produces a very short time domain pulse that is able to propagate without the need for an additional radio frequency (RF) mixing stage. The RF mixing stage takes a baseband signal and “injects” a carrier frequency or translates the signal to a frequency that has desirable propagation characteristics. The very wideband nature of the UWB signal means it spans frequencies commonly used as carrier frequencies. Since high burst data rates are achievable with UWB systems, a sensor employing UWB can transfer its data payload quickly and spend much of the rest of the time “asleep” or in a low-power state [40]. 2.3.7

System-on-Chip

The system-on-chip (SOC) approach used by some wireless platforms integrates both the MCU and transceiver capabilities into a single die. The key benefits of this approach are the ability to reduce the overall dimensions of the sensor platform, and a more simplified design that can improve power efficiency. SOC designs are available both commercially and as bespoke research platforms. The nRF24E1 SOC, utilized by the MIT’s MITes [41] sensor, has a 2.4-GHz transceiver with an embedded 8051 MCU, 9-channel, 12-bit ADC, and peripherals. The REFRAIN [42] and RISE [43] from MIT and UCLA are based on the Chipcon CC1010 SOC, which features a 300 to 1,000 MHz RF transceiver, UHF transceiver, and an 8051 controller with 32 KB of flash program memory. Some researchers have taken the approach of developing their own custom SOC. The Berkeley Spec [44, 45] project’s sensor platform, which was only 5 mm2, was based on a SOC design. It featured an AVR-like RISC core with an FSK transmitter. In tandem with a very small footprint, Spec was extremely power efficient. It consumed approximately 1 pJ per instruction, compared to 1 nJ for a standard ARM-core MCU. 2.3.8

Antenna Designs for Wireless Sensors

To understand the complexities associated with reliable connections in WSN applications, a simple introductory knowledge of antennas is important. In his book Smart Antennas for Wireless Communication, Frank Gross [46] states, “It is critical to match the individual antenna behavior with the overall system requirements.” In healthcare sensing application, the importance of this statement cannot be overemphasized. In numerous field studies and design audits, failure to match the antenna to the intended system application has led to poor or low quality of service for the wireless sensor network. Here we will cover some of the basics of antenna types and theory. Basically, an antenna is a transducer designed to transmit or receive radio waves, which are a class of electromagnetic waves [47]. Effectively, an antenna is simply a device that converts RF electrical currents into electromagnetic waves, and vice versa.

30

Sensor Network Technologies

The regions of electromagnetic energy emission from antennas have been classified as the antenna region; the reactive near field region, Fresnel region or radiating near field; and the Fraunhofer or far field (Figure 2.5). The antenna region is the area bound by the circumference or length of the antenna [46]. The reactive area is described by energy stored near the antenna, which does not radiate and is considered to be the terminal impedance of the antenna. The Fresnel region is the close-in region of an antenna, where the angular field distribution is dependent upon the distance from the antenna. These first two regions are not considered for the rest of the text as they are often left to the designers of the antennas or radios. The Fraunhofer region is where the angular field distribution is essentially independent of distance from the source of emission, or the antenna. The Fraunhofer region or far field is the principle region of operation for most antennas. When showing the coverage of an antenna, the radiation pattern is normalized on a polar plot showing the radiated power density, which is measured at a constant distance from the antenna in a horizontal or vertical plane. In describing the power of the antenna, gain used to indicate how many times larger the power density of the antenna’s propagation is than the power density from an isotropic radiator at the same distance. Antenna gain shouldn’t be misunderstood as the amplification of power, as it is the bundling of the available radiated power in certain directions. Antenna gain is given in units of decibels (dB). An antenna’s ability to not only radiate energy but also receive energy is known as reciprocity. As electromagnetic fields leave the antenna they are propagated; in doing so the propagation experiences any combination of spreading, absorption, attenuation, or reflection [46]. One combination of these elements is Rayleigh scattering, in which the electromagnetic signal strikes objects smaller than the wavelength, like fog or humidity. If the signal strikes a structure with a change in dielectric, the electromagnetic signal may be refracted or reflected, causing a change in its direction. Lastly,

Figure 2.5

Antenna regions.

2.3 WSN Technologies

31

the electromagnetic signal may strike a corner or edge, causing the signal to be diffracted. In the healthcare field, most wireless network are indoors and therefore suffer from combinations of these impediments to theoretical propagation. In the field environment, the receiver does not only get the signal through the direct path, but from additional reflections, diffracted, and scattered rays. The reception of the signal from these alternative paths is called multipath propagation, which causes fading and intersymbol interference. Fading happens when the time difference between the arrival of the direct and the delayed reflected wave is within the order of magnitude of the carrier frequency’s period. When the time difference of arrival (TDOA) is an integer multiple of the period, the two waves interfere constructively; the received signal is stronger than without fading. When the time difference is an odd multiple of the half-period time, the direct and the indirect components subtract from each other; in the worst case they totally cancel out. If a receiver is moved into an environment with multipath transmission, there will be alternating stronger and weaker signals. The damage from the mutual cancellation is much more significant than the advantage from the constructive interference at other locations. If the time difference, τ, is on the order of magnitude of the bit duration of the packet being sent, multipath transmission leads to intersymbol interference. Smaller rooms can cause a substantially large amount of intersymbol interference, causing high bit error rates [47]. To understand indoor propagation, we’ll examine two models that have recently gained in popularity to characterize the path loss [48]. The first is the International Telecommunication Union (ITU) indoor propagation model, which estimates the path loss inside a room or a closed area inside a building delimited by walls of any form. The model is used for frequencies from 900 MHz to 5.2 GHz. The mathematical model is given by L=20 * log f

N log d

Pf(n)

28

where L is the total path loss in decibels, f is the transmission frequency in megahertz, d is the distance in meters, N is the distance power loss coefficient, n is the number of floors between the transmitter and receiver, and Pf(n) = the floor loss penetration factor. The distance power loss coefficient is empirically derived and ranges from 28 to 33 for office areas depending on frequency. The floor penetration loss factor is an empirical constant dependent on the number of floors the waves penetrate. The values for the constant are four times the number of floors for residences, and have a range of 3 to 20 for office complexes. The second model is the log distance path loss model that predicts the path loss a signal encounters inside a building over distance. L=L0

10

log d/d0

Xg

where L demotes total path loss inside a building in decibels, L0 is the path loss at reference distance, in decibels, γ is the path loss distance exponent, and Xg is a Gaussian random variable with zero mean and standard deviation, reflecting the shadow fading or slow fading.

32

Sensor Network Technologies

Since both models rely on empirical constants that are frequency-dependent as well as architecturally and materially dependent, determining the values of these constants can be challenging. The most common basic physical types of antenna include dipoles, monopoles, array antennas, and patch antennas (Figure 2.6) [48]. A dipole antenna is formed by two conductors with a total length proportional to the compared wavelength of the carrier frequency. In practice, the dipole antenna is designed so that the antenna length is half of one wavelength, and is called a half-wave dipole. The half-wave dipole antenna requires differential feeds, as its two terminations have the same impedance to ground. What’s nice about this characteristic is that if the both the transmitter and receiver on a WSN radio have differential ports, then a half-wave dipole can be used efficiently. In the case of a single-ended transmitter and receiver, a balun should used along with the half-wave dipole antenna. Commercially-available dipoles often have the balun built into the antenna. The half-wave dipole may be detuned by materials with a dielectric constant larger than one in its reactive near field. In the field of health care applications, one should know that the human body has a large dielectric constant—near 75—which varies somewhat, based on the body mass. Since half-wave dipoles are electrical antennas, when used near the human body or in handheld applications, particular attention should be given to detuning the antenna. Far-field emission patterns for dipoles resemble a slightly flattened torus, where the conducting elements are in the center. The field is symmetrical around its axis, the three-dimensional radiation pattern rotates around the wire axis with no radiation on the axis of the wire. The isotropic gain of a half-wave dipole antenna is 2.15 dB. Therefore, in the direction perpendicular to the wire axis, the radiated power density is 2.15 dB larger than that of the isotropic radiator. In many healthcare applications, dipole antennas are physically too large for typically body-worn sensors. Furthermore, the differential feeds required by a dipole antenna will overcomplicate the design of a healthcare sensor. In these cases, a monopole antenna is often used. A monopole is constructed by replacing one branch of a dipole antenna with an infinitely large ground plane. Using the physical effect of mirroring, the radiation pattern above the ground plane remains unaffected in the monopole antenna application. When constructed in this manner, the ground plane is at right angles to the remaining conductor. Assuming that the

Figure 2.6

Radio

Radio

Radio

Radio

(a)

(b)

(c)

(d)

Antenna types (a) dipole, (b) monopole, (c) array, and (d) patch.

2.3 WSN Technologies

33

ground plane is effectively large, the monopole antenna then has characteristics similar to the dipole. The general application of a monopole antenna usually leads designers to make it as long as space permits, while at other times form-factor design constraints require it to be smaller than one-quarter wavelength. A monopole shorter than a quarter-wavelength may be considered as a quarter-wave monopole, which is used at a frequency lower than the frequency of resonance. The radiation resistance of an ideal quarter-wave monopole is half that of a dipole. Similar to the half-wave dipole, the quarter-wave monopole is an electrical antenna; influenced by the dielectric constant of the material in the reactive near field. Theoretically all the power is concentrated in the half space about the ground, which would make the gain on the monopole 3 dB, higher than the dipole [48]. In reality, infinite ground planes don’t exist, and large ground planes (relative to the antenna size) encumber the design and usability of a device. In practice, grounded stubs or ground planes near the conductor are constructed to make the effective monopole. Typically, due to material defects and design constraints, the ground plane becomes nonsymmetric. Once the ground plane becomes nonsymmetrical, the direction of polarization will be tilted toward the larger part of the ground plane, remaining linear, but with a nonuniform emissions field. Both previously mentioned antennae are single units, but the integration of these in a single structure can be made to obtain wider sidebands and unique emission field patterns. These integrated antennas are called array antennas. The most straightforward array is a linear array, made from a straight row of elements. The Yagi antenna is an example of a fairly high-gain array where most of the elements are fed parasitically from one or more driven elements. Finally, as antenna construction moves from lines of conductor to planes of conductor, a new type of antenna is produced called the microstrip patch antenna, or patch antenna. In practice it is popular to use a printed resonant antenna on a printed circuit card for narrowband microwave wireless links that require semihemispherical coverage. Due to the hemispherical cover, the patch antennas are combined with arrays of other patches to achieve complex emission patterns. Both array antennas and patch antennas are often used in fixed-mount applications, when the antennas can be positioned to take advantage of the directional aspects of the emission fields [46–48]. 2.3.9

Operating Systems

The operating system (firmware) of the wireless sensor node plays a vital role in the overall capabilities and performance of the platform. The limited node resources such as computational capability, available memory—normally in the range of kilobytes—power consumption, and the application characteristics of wireless sensor networks place specific requirements on the operating system. Early research into operating systems for sensor networks lead to the development of TinyOS by researchers at UC Berkeley [49]. It is based on a structured event-driven execution model and component-based software libraries that provides a high level of hardware abstraction with a small memory footprint and excellent power management. An open source project, TinyOS has become the de facto industry-standard operat-

34

Sensor Network Technologies

ing system for sensor network research and applications. TinyOS is written in nesC [50], which is a dialect of the C programming language. nesC supports the event-driven processing that is typical of many wireless sensors, which remain “asleep” until sensors acquire data or receive messages. The TinyOS developers decided to leave out some features commonly found in larger operating systems, such as multithreading and run-time module loading, though TinyOS provided a mechanism for tasks that run to completion but can be interrupted by higher priority tasks and then resumed. Exclusion of multiple execution threads has lead to the development of alternative operating systems for wireless sensor applications that provide this capability; these include MANTIS [51], SOS [52], and Contiki [53]. Another approach, which employs a distributed model, is implemented by MagnetOS [54]. MagnetOS provides a single system image of a unified Java virtual machine to applications over an ad hoc collection of heterogeneous nodes. It treats the whole sensor network as one computational device. It automatically partitions applications into components and places them on appropriate nodes within the ad hoc network. MagnetOS consists of a static code partitioning service and a local runtime that supports the partitioned applications. Squawk VM [55] is a Java Virtual machine being developed for small platforms by Sun Microsystems. The virtual machine approach brings a number of potential advantages to the developer, such as the means to run diagnostics procedures remotely and to debug and modify code remotely. There is also the potential for managing and upgrading a wireless sensor deployment in situ. 2.3.10

Sensors and Actuators for Healthcare WSNs

The sensors that are deployed in a WSN reflect the data that needs to be collected and the type of actuation that is envisaged by the clinician and the engineer working together. This section looks at three main types of sensors: physical transducers, chemical sensors, and biosensors. 2.3.10.1

Physical Transducers

Physical transducers monitor some physical phenomenon such as light or movement. Such sensors do not have to be directly in contact with the patient and so are often more rugged and more reliable in long-term deployments. They are generally low power and often low cost. They are the most suitable for scale-up and for real-time data generation. Although they are not specific sensors for chemical or biological species, they can provide general information about the environment and personal health. Examples of physical transducers include thermistors, vibration sensors, accelerometers, photodetectors, pressure sensors, acoustic sensors, and noncontact conductivity/impedance sensors. Low-cost spectral information can be generated by combining selective light sources like LEDs (narrowband emitters) with photodetectors so that the spectral region is associated with the particular absorbance band of a specific target [56]. An example is the use of red LEDs in pulse oximetry to determine the varying concentration of oxygenated hemoglobin in real time. Important developments in this area include the emergence of new materials such as soft polymer sensors and actuators (e.g., that are biocompatible and can

2.3 WSN Technologies

35

mimic the function of muscles) [57]. These are increasingly being integrated into lab-on-a-chip devices to provide low-cost, low-power methods for moving samples and reagents around microfluidic manifolds, and perform relatively complex analytical measurements in a compact device [58]. They are also being integrated into textiles to generate wearables capable of sensing movement and breathing. Related devices in this class also include ECG/EKG/EMG electrodes that provide real-time data on aspects of heart function [59]. A particular focus for research in this field is on how to obtain good quality data from dry contact electrodes. Video cameras are currently underutilized as information sources. In addition to the image and sound information, they can be coupled with chemo-responsive dyes to generate chemical information related to their field of view (see below). 2.3.10.2

Chemical Sensors

In contrast to physical transducers, chemical sensors must have an active surface or membrane that changes when exposed to the patient and in so doing generates the chemically selective signal. Chemical sensors are broadly divided into electrochemical (e.g., ion-selective electrodes, used extensively for blood electrolyte profiling) and optical sensors (incorporating a dye that changes color or fluorescence in the presence of a particular target—the dye change is detected using a spectrometer or low-cost LED photodetectors). Many chemical sensors can now be made with a very small physical footprint and at low cost, but tend to be less reliable than transducers in long-term deployment. Common targets include electrolytes in blood, sweat, saliva, gases in breath such as ketones, aldehydes, and amines, which indicate certain conditions such as diabetes, stomach cancer, and ulcers. They are also employed extensively for measuring specific targets like spoilage emissions from food (e.g., amines in packaged seafood) [60] and in the environment (metals in water, nutrient loading in rivers and lakes) [61] and gases in built up areas (e.g., SOx and NOx in cities) [62]. They also have extensive use in security/threat detection such as deliberate contamination of rivers and lakes, public spaces and air by toxic materials, although detection of bio/chemo-warfare agents in real time remains largely beyond the current state-of-the-art [63]. Increasingly, chemical sensors will be linked with transducers in a sensor network to provide heterogeneous information sources for applications in personal health and environmental monitoring. 2.3.10.3

Biosensors

Biosensors are the most complex of the three classes of sensor, and tend to have the shortest lifetime, essentially only suitable for single shot measurements or short-term deployments (days at the most). They incorporate a biological species (almost always an antibody or enzyme) in the device that selectively interacts with a specific component in the sample, and generates the signal (usually electrochemical or optical). Antibody-based biosensors often require several analytical steps to be completed before the result is obtained, although there are emerging approaches that facilitate direct (unlabelled) measurements such as surface plasmon resonance [64].

36

Sensor Network Technologies

Biosensors include DNA profiling devices as well as examples of automated instruments that can perform the operations required to generate sequences from samples (e.g., sampling, incubation, lyseing, DNA extraction, PCR, detection). These sensors are primarily targeted at field detection of biowarfare agents such as anthrax or bubonic plague [65]. However, they are currently very complex, expensive, and are not suited to large-scale deployment. 2.3.10.4

Lab-on-a-Chip

Lab-on-a-chip devices are essentially scaled-down analytical instruments that can perform complex operations on samples including sample processing, reagent addition, detection, and calibration [66]. They offer tremendous scope to automate many analytical measurements including diagnostics. Examples include diagnostic instruments for home use that include throwaway biosensors (e.g., glucose detectors) and devices for continuous real-time environmental monitoring. There will be a huge expansion in the availability of home-based instruments for monitoring specific disease markers and therapeutics in blood (so-called theranostics). While these are not focused on long-term health maintenance, they do provide a snapshot of the levels of these markers, thus providing a means for personal control of a disease state, In addition, through digital communications, the information can be made available to remote caregivers and specialists for further analysis. A survey of available sensors is shown in Table 2.6. Figure 2.7 shows sensors in place in WSN for healthcare trials.

2.4

Conclusion This chapter has introduced the most important technology elements for WSN solutions. While WSNs cover a full gamut from server to aggregator to sensor, the servers and aggregators typically take the form of PCs and/or smartphones/PDAs. As a result, they are not described in any detail in this chapter. The range of offerings for each main technology area is quite substantial, with many dozens of devices, modules, sensors, microcontrollers, and radios available. These have been explored here, but it must be borne in mind that new offerings appear on the market all the time. The systems software (firmware) available must also be taken into account. Which technologies to use for which new solution is the key question explored in this book; Chapter 4 focuses specifically on technology selection.

2.4 Conclusion Table 2.6

37

Sensors

Sensor

Signal Type

Sample Rate

Behavioral Biomarker

ECG

Electric

250 Kbs

Beat-to-beat variability of the heart and heart waveform characteristics

Sphygmomanometer

Electromechanical

<1 Hz

Blood pressure

Electromyograph (EMG)

Electromechanical

2 kHz

Muscle movement

Acelerometers or gyroscopes

Electromechanical

100 kHz

Body worn, embedded in everyday devices or environmental for motion, gate, movements

Respiration

Electromechanical

150 Hz

Breathing rate

Inclinometer

Electromechanical

100 Hz

Walking uphill or motion/movement of a device

Pulse ox

Optical

<1 Hz

O2 saturation and uptake

Gate/falls

Electromechanical

100 kHz

Footfall, stride, motion

Heart rate

Electromechanical

60 kHz oversampled

General pulse with no ECG information

Location outdoor

Radio frequency

5 GHz

Motion, movement, location, social engagements

Location indoor

Radio frequency

2.4 GHz

Motion, movement, social copresences

EEG

Electromechanical

250 Kbs

Brainwave activity

Dexterity

Mechanical

100 kHz

Finger dexterity, endurance

Temperature

Thermal

<1 Hz

Body temperature and environmental temperature

Eating

Electromechanical

250 Kbs

Chewing or mouth motion

Voice recognition

Acoustic

250 Kbs

Pauses, key words, queries for daily testing

Eye motion and gaze

Optical

250 Kbs

Galvanic skin response

Electrochemical

<1 Hz

Salt change or chemical changes on the skin

Sleep quality

Electromechanical

250 Kbs

Actrigraphy in the bed

Vascular Doppler acoustics

Acoustical

250 Kbs

Heartbeat and respiration from RF Doppler readings

Chemical sensing

Chemical

<1 Hz

Environmental chemicals, food spoiling due to forgetting

Passive IR motion

Thermal

<1 Hz

Motion or activity in room for activity-daily-living detection

Doors open or close

Mechanical

<1 Hz

Doors, drawers, or closets opening for activitydaily-living detection

Light sensors

Optical

<1 Hz

Light activity in a room; doors, drawers, or closets opening for activitydaily-living detection

38

Sensor Network Technologies

Table 2.6 (continued) Sensor

Signal Type

Sample Rate

Behavioral Biomarker

Airflow

Electromechanical

100 kHz

Lung capacity or airflow in the environment

Echograph

Electromechanical

250 Kbps

Voice-level sensing

Acoustical

250 Kbps

Speech volume for the patient

Speech attenuation

Acoustical

250 Kbps

Patients ability to project speech

Verbal pausing

Acoustical

250 Kbps

Duration of pauses

Medication adherence

Mechanical

<1 Hz

Medication adherence

Appliance usage

Electrical

<1 Hz

Activities of daily living (TV, radio, fridge, microwave, electric stove, gas stove, etc.)

Television remote control Optical monitor

60 kHz

Activities of daily living (TV or radio usage)

Phone sensor

Electrical

<1 Hz

Activities of daily living (phone usage, caller ID, embedded testing on key pad, on/off hook, voice message forwarding, DTMF)

Magnetometer

Magnetic

<1 Hz

Car presence

Pulse transit time

Electrical

250 Kbs

Heartbeat in arm

Multisensor fusion Electric, optical (accelerometer, barometer, mechanical temperature, light)

250 Kbs

Activity of daily living (general motion)

Strain

Mechanical

250 Kbs

Activity of daily living (general motion, chair occupancy, floor movement)

Color intensity

Optical

<1 Hz

Doormat

Mechanical

<1 Hz

Threshold occupancy

Device prescience detecRadio frequency tion, movement and position through RFID

2.4 GHz

Object tracking for activity of daily living detection

Mechanical rotation

Mechanical

100 kHz

Partial opening or movement for motion or activity of daily living detections

Floor vibration

Mechanical

200 Hz

Gate or Fall

Bend or inclination

Mechanical

250 Kbps

Partial opening or movement for motion or activity of daily living detections

Barometer

Mechanical

<1 Hz

Going up stairs or atmospheric pressure changes

Pressure

Mechanical

100 kHz

Activity of daily living, bed activity, embedded scales

Grip sensing

Mechanical

<1 Hz

2.4 Conclusion

39

Table 2.6 (continued) Sensor

Signal Type

Sample Rate

Behavioral Biomarker

Water usage

Thermal/mechanical

<1 Hz

Activity of daily living, cooking, dishwashing, bathing, gardening

Proximity

Optical

<40 Hz

Activity of daily living

Chair occupancy

Mechanical

<1 Hz

Activity of daily living

Door Motion

Elder Using PC Couch Pad

Motion

Elder Badge Presence Lamp

Base Station Doormat Switch Telephone Board

Figure 2.7

Sensors in place in a home trial.

References [1]

[2]

[3] [4]

[5]

Bai, H., Atiquzzaman, M., and. Lilja, D., “Wireless Sensor Network for Aircraft Health Monitoring,” Proc 1st International Conference on Broadband Networks (Broadnets ’04), San José, CA, Oct. 25–29, 2004, pp. 748–750. Mainwaring, A., Polastre, J., Szewczyk, R., Culler D. and Anderson, J., “Wireless Sensor Networks for Habitat Monitoring,” Proc. of the ACM International Workshop on Wireless Sensor Networks and Applications, Atlanta, GA, Sept. 28, 2002, pp. 88–97. Mills, K., Scholtz, J., and Sollins, K., (eds), “Special Issue on Smart Spaces and Environments,” IEEE Personal Communications, Vol. 7, Issue 5, 2000, pp. 35. Srivastava, M., Muntz R., and Potkonjak, M., “Smart kindergarten: sensor-based wireless networks for smart developmental problem-solving environments,” Proc 7th International Conference on Mobile Computing and Networking, Rome, Italy, July 16–21, 2001, pp. 132–138. Werner-Allen, G., K. Lorincz, M. Ruiz, O. Marcillo, J. Johnson, J. Lees, and M. Welsh, “Deploying a Wireless Sensor Network on an Active Volcano,” IEEE Internet Computing,

40

Sensor Network Technologies

[6]

[7]

[8] [9] [10]

[11] [12] [13]

[14]

[15] [16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

Special Issue on Data-Driven Applications in Sensor Networks, March/April, 2006, pp. 18–25. Werner-Allen, G., Johnson, J., Ruiz, M., Lees, J., and Welsh, M., “Monitoring Volcanic Eruptions with a Wireless Sensor Network,” Proc.2nd European Workshop on Sensor Networks (EWSN’05), Istanbul, Turkey, Jan. 31–Feb. 2, 2005, pp. 108–120. Hongliang R, Meng, M. Q.-H. and Chen, X., “Physiological Information Acquisition through Wireless Biomedical Sensor Networks,” Proc IEEE International Conference on Information Acquisition, June 27–July 3, 2005, Hong Kong and Macau, China, pp. 483–488. WINS project, Rockwell Science Center, http://wins.rsc.rockwell.com, June 2006. Hill, J. L., and Culler, D. E., “Mica: A Wireless Platform for Deeply Embedded Networks,” IEEE Micro, Vol. 22, No. 6, pp.12–24, Nov. 2002. Anastasi, G., Falchi, A., Passarella, A., Conti, M., and E. Gregori, “Performance measurements of motes sensor networks,” Proc 7th ACM International Symposium on Modelling, Analysis and Simulation of Wireless and Mobile Systems, Venice, Italy, 2004, pp. 174–181, Rice University, “Rice CMC Lab Project—Gnomes Sensor Network,” http:// www.ece.rice.edu/~cavallar/cmclab/, Nov. 2007. ETH Zurich, “BTnodes – A Distributed Environment for Prototyping Ad Hoc Networks,” http://www.btnode.ethz.ch/, Nov. 2007. Bhatti, S., J., Carlson, H., Dai, J., Rose, A., Sheth, B., Shucker, J., and Han, D. R., “MANTIS: system support for multimodal Networks of in situ sensors,” Proc 2nd ACM International Conference on Wireless Sensor Networks and Applications, San Diego, CA, Sept. 19, 2003, pp 50–59. Klemmer, S., Waterson, S. and Whitehouse, K., “Towards a Location-Based Context-Aware Sensor Infrastructure,” CS Division, EECS Department, University of California at Berkeley, 2000. Zhao F. and Guibas, L. J., Wireless Sensor Networks—An Information Processing Approach, Elsevier Publishers, 2004. Polastre, J., R. Szewczyk, and D. Culler, Telos, “Enabling Ultra-Low Power Wireless Research,” Proc 4th International Symposium on Information Processing in Sensor Networks, Los Angeles, CA, Apr. 24–27, 2005, pp. 364–369. Intanagonwiwat, C., Govindan R., and Estrin, D., “Directed diffusion: a scalable and robust communication paradigm for sensor networks,” Proc 6th Annual International Conference on Mobile Computing and Networking, Boston, MA, 2000, pp 56–67. Culler, D. J. Hill, M. Horton, K. Pister, R. Szewczyk, and A. Woo, “MICA: The Commercialization of Microsensor Motes,” http://www.sensorsmag.com/articles/0402/40/, Nov. 2007. Crossbow Technologies, “Crossbow Technology: Wireless Sensor Networks: MICAz 2.4 GHz—Wireless Module,” http://www.xbow.com/Products/productsdetails.aspx?sid=164, Nov. 2007. Farshchi, S., Nuyujukian, P.H., Pesterev, A., Mody, I., and Judy, J. W., “A TinyOS-Based Wireless Neural Sensing, Archiving, and Hosting System,” Proc 2nd IEEE EMBS Conference on Neural Engineering, Arlington, VA, Mar. 16–19, 2005, pp. 5–8. Nachman, L., Kling, R., Adler, R., Huang, J. and Hummel, V., “The Intel Mote Platform: A Bluetooth-Based Sensor Network for Industrial Monitoring,” Proc 4th International Symposium on Information Processing in Sensor Networks, Los Angeles, CA, 2005. Crossbow Technology Inc., “Imote2—High-Performance Wireless Sensor Network Node,” http://www.xbow.com/Products/Product_pdf_files/Wireless_pdf/Imote2_ Datasheet.pdf, Nov. 2007. Atmel Corp, “AVR 8-bit RISC from Atmel,” http://www.atmel.com/products/AVR/, Nov. 2007.

2.4 Conclusion

41

[24] Texas Instruments Inc., “MSP430 Ultra Low-Power Microcontrollers Overview from Texas Instruments,”http://focus.ti.com/mcu/docs/mcuprodoverview.tsp?sectionId= 95&tabId=140&familyId=342, Nov. 2007. [25] University College Cork, “The DSYS25 Sensor Platform,” http://www.cs.ucc.ie/ misl/dsystems/HTML/dsys25.php, Nov. 2007. [26] O’Flynn, B., A. Lynch, K. Aherne, P. Angove, J. Barton, S. Harte, C. O’Mathuna, D. Diamond, and F. Regan, “The Tyndall Mote. Enabling Wireless Research and Practical Sensor Application Development,” Adjunct Proc. Advances in Pervasive Computing, Dublin, Ireland, May 7–10, 2006, pp. 21–26. [27] Arvind, D. K and Wong, K. J., “Speckled Computing: Disruptive Technology for Networked Information Appliances,” IEEE International Symposium Consumer Electronics, Reading, U.K., Sept. 1–3, 2004, pp. 219–223. [28] Lorincz, K., Kuris, B., Ayer, S.M., Patel, S., Bonato P. and Welsh, M., “Wearable wireless sensor network to assess clinical status in patients with neurological disorders,” Proc 6th international conference on Information processing in sensor networks, Cambridge, MA, Apr. 25–27, 2007, pp 563–564. [29] Lo, B., Thiemjarus, S., King, R., and Yang, G-Y., “Body Sensor Network—A Wireless Sensor Platform for Pervasive Healthcare Monitoring,” Adjunct Proc 3rd International Conference on Pervasive Computing, Munich, Germany, May 8–13, 2005, pp 77–80. [30] Sentilla, “Tmote Mini Datasheet,” http://www.sentilla.com/pdf/eol/ Tmote_Mini_Datasheet.pdf, Nov. 2007. [31] Dynastream Innovations Inc, “This is ANT, the Wireless Sensor Network Solution,” http://www.thisisant.com/index.php?section=30, Nov. 2007. [32] Healey, C. A., “Gathering Motion Data Using Featherweight Sensors and TCP/IP over 802.15.4,” Workshop on On-Body Sensing, IEEE International Symposium on Wearable Computing, Osaka, Japan, 18–21 October 2005. [33] Wexler, J., “Zigbee Vendor Group to Wireless Enable Facilities Monitoring,” http://www.networkworld.com/newsletters/wireless/2003/0825wireless1.html, Sept. 2006. [34] Zigbee Alliance, Information and Resources, http://www.zigbee.org/en/resources/ #WhitePapers, Sept. 2006. [35] Dunkels, A., “Full TCP/IP for 8-Bit Architectures,” Proc. of the First International Conference on Mobile Applications, Systems and Services (MOBISYS 2003), San Francisco, CA, May 2003. [36] Dunkels, A., O. Schmidt, and T. Voigt, et al., “Protothreads: Simplifying Event-Driven Programming of Memory-Constrained Embedded Systems,” Proc. of the Fourth ACM Conference on Embedded Networked Sensor Systems (SenSys 2006), Boulder, CO, November 2006. [37] Christian, A., and J. Healey, “Gathering Motion Data Using Featherweight Sensors and TCP/IP over 802.15.4,” Workshop on On-Body Sensing, IEEE International Symposium on Wearable Computing, Osaka, Japan, October 18–21, 2005. [38] “The uIP Embedded TCP/IP Stack,” http://www.sics.se/~adam/uip/, accessed Feb. 29, 2008. [39] Internet Society, SIP: Session Initiation Protocol, Internet RFC 3261, 2002. [40] Opperman, L. Stoica, A. Rabbachin, Z. Shelby and J. Haapola, “UWB Wireless Sensor Networks: UWEN—A Practical Example,” IEEE Radio Communications, December 2004, pp. 27–32. [41] Munguia, E., Tapia, S. Intille, S., Lopez, L., and Larson, K., “The design of a portable kit of wireless sensors for naturalistic data collection,” Proc 4th International Conference of Pervasive Computing, Dublin, Ireland, May 7–10, 2006, pp. 117–134. [42] MIT Media Lab, “RF Random Access Integrated Node,” http://www.media.mit.edu/ resenv/rfrain/, Nov. 2007.

42

Sensor Network Technologies [43] Banerjee, A., Mitra, A., Najjar, W., Zeinalipour-Yazti, D., Kalogeraki, V., and Gunopulos, D., “RISE—Co-S : High Performance Sensor Storage and Co-Processing Architecture,” Proc 2nd Annual IEEE Communications Society Conference on Sensor and Ad Hoc Communications and Networks, Santa Clara, CA, Sept. 26–29, 2005, pp. 1–12. [44] Frost Gorder, P., “Sizing Up Smart Dust,” Computing in Science & Engineering, November/December, 2003, pp. 6–9. [45] Warneke, B.A. and K.S.J. Pister, “An Ultra-Low Energy Microcontroller for Smart Dust Wireless Sensor Networks” Digest of Technical Papers IEEE Solid-State Circuits Conference (ISSCC), San Francisco, CA, Vol. 1, Feb. 15–19, 2004, pp. 316–317. [46] Gross, F., Smart Antennas for Wireless Communications, New York: McGraw-Hill Professional, 2005, pp. 35. [47] Loy, M., and I. Sylla, “ISM-Band and Short Range Device Antennas,” Texas Instruments Application Report SWRA046A, August 2005. [48] Seidel, S., and T. Rappaport, “900 MHz Path Loss Measurements and Prediction Techniques for In-Building Communication System Design,” Proc. 41st IEEE Vehicular Technology Conference Gateway to the Future Technology in Motion, St. Louis, MO, May 19–22, 1991, pp. 613–618. [49] UC Berkeley, “TinyOS Community Forum, an Open-Source OS for the networked sensor regime,” http://www.tinyos.net/, Nov. 2007. [50] Gay, D. P. Levis, R. von Behren, M. Welsh, E. Brewer, and D. Culler, “The nesC language: A holistic approach to networked embedded systems,” Proc ACM Conference on Programming Language Design and Implementation (SIGPLAN 2003), San Diego, CA, June 9–11, 2003, pp. 1–11. [51] Abrach, H., S. Bhatti, J. Carlson, H. Dai, J. Rose, A. Sheth B. Shucker, J. Deng, and R. Han, “Mantis—System supports for multimodal networks on in situ sensors,” Proc 1st International Conference on Embedded Networked Sensor Systems, Los Angeles, CA, Nov. 5–7, 2003, pp. 336–337. [52] Han, S., R. Rengaswamy, R.S. Shea, E. Kohler, and M.B Srivastava, “A Dynamic Operating System for Sensor Nodes,” Proc 3rd International Conference on Mobile Systems, Applications and Services (Mobisys), Seattle, WA, Jun. 6–8, 2005, pp. 163–176. [53] Dunkels, A., B. Gronvall and T. Voigt, “Contiki—a lightweight and flexible operating system for tiny networked sensors,” Proc 29th Annual IEEE International Conference on Local Computer Networks, Tampa, FL, Nov. 16–18, 2004, pp. 455–462. [54] Barr, R., Bicket, J. C., Dantas, D. S., Du, B., Danny Kim T. W., Zhou B., and Gün Sirer, E., “On the need for system-level support for ad hoc and sensor networks,” ACM SIGOPS Operating Systems Review, Vol. 36, No. 2, 2002, pp. 1–5. [55] Sun Microsystems, “Squawk Overview,” http://research.sun.com/projects/dashboard.php?id=155, Nov. 2007. [56] King-Tong, L., S. Baldwin, and M. O’Toole, et al., “A Low-Cost Optical Sensing Device Based on Paired Emitter–Detector Light Emitting Diodes,” Anal. Chim. Acta., Vol. 557, No. 1–2, 2006, pp. 111–116. [57] Brady, S., K. T. Lau, and W. Megill, et al., “The Development and Characterisation of Conducting Polymeric-Based Sensing Devices,” Synthetic Metals, Vol. 154, No. 1–3, 2005, pp. 25–28. [58] Causley, J., S. Stitzel, and S. Brady, et al., “Electrochemically-Induced Fluid Movement Using Polypyrrole,” Synthetic Metals, Vol. 151, No. 1, 2005, pp. 60–64. [59] Linz, T., C. Kallmeyer, and R. Aschenbrenner, et al., “Embroidering Electrical Interconnects with Conductive Yarn for the Integration of Flexible Electronic Modules into Fabric,” Proc 9th IEEE International Symposium on Wearable Computers (ISWC’05), Osaka, Japan, Oct. 18–21, 2005, pp. 86–91. [60] Byrne, L., Lau, K. T., and Diamond, D., “Monitoring of Headspace Total Volatile Basic Nitrogen from Selected Fish Species Using Reflectance Spectroscopic Measurements of pH Sensitive Films,” Analyst, Vol. 127, 2002, pp. 1338–1341.

2.4 Conclusion

43

[61] Minogue, E., Bowden, M., and Diamond, D., “Autonomous Analytical Devices: Their Role in Building an Environmental Nervous System,” Proc 2nd Senspol Workshop Response to New Pollution Challenges, King’s College, London, June 4–7, 2002, pp. 150–155. [62] EPA, Environmental Protection Agency Ireland, http://www.epa.ie/OurEnvironment/ Air/AccessMaps/DublinAreaMap/, Nov. 2007. [63] Diamond, D., “Internet-Scale Sensing—Is it More Than a Dream?” in Advances in Sensing with Security Applications, J. Byrnes and G. Ostheimer (eds.), Vol. 2, Springer, 2006, pp. 121–146. [64] Turner, P., and R. Renneberg, “Perspectives in Biosensors,” in Advances in Biosensors, Vol. 5, B. Malhotra and A. Turner (eds.), Amsterdam, Netherlands: Elsevier, 2003, pp. 1–12. [65] Idaho Technology Inc., http://www.idahotech.com/, Nov. 2007. [66] Boone, T. D., Z. H. Fan, and H. H. Hooper, et al., “Plastic Advances Microfluidic Devices,” Anal. Chem., Vol. 74, No. 3, 2002, pp. 78A–86A.

CHAPTER 3

Informing Your Design 3.1

Introduction The design of a wireless sensor network solution for healthcare is a collaborative and multidisciplinary process involving the engineer, the clinician, the end user, ethnographers, interaction designers, and others. Two parallel imperatives must be met—the solution must meet the clinical requirements and it must be appropriate for and acceptable to the end users. The requirements identified by the clinician or researcher (referred to simply as the clinician, for the sake of brevity) are typically the basis for the overall project—the project is created to address the knowledge requirement of the clinician. The clinician may express this requirement as a research hypothesis, linking some observable end-user characteristic(s) to a cause. The clinician may also suggest an experimental approach for the confirmation of the hypothesis, which the engineer can consider as a possible input to his or her solution design. The clinician’s requirements and background knowledge may be described using a clinical requirements document (CRD). End user experience and acceptance is supported by the use of ethnography and usage modeling. Ethnography provides qualitative insights into both the clinical and home healthcare environments, as well as the daily routines of the participants in these settings. Ethnography often also sets the context and the boundary conditions for the use of technology. Usage modeling involves the full project team, from ethnographers to engineers, working together to map out and explore the end user’s lifestyle, with a focus on the user’s experience of the technology. The CRD and end user analysis feed into the creation of a requirements statement for the project. A useful way to describe many requirements is to draw up a set of use cases. Use cases are documented examples of how the system behaves in response to user input. Finally, the outline design can be assessed using failure modes and effects analysis (FMEA). This process again involves the full multidisciplinary team, this time to identify and to prioritize the ways in which the solution could fail to achieve its objectives. The top-priority failure modes can thus be identified and addressed in the design. Having informed, outlined, and analyzed the design, the engineer will now be ready to select the most appropriate technologies for his or her solution. This is addressed in the next chapter.

45

46

3.2

Informing Your Design

Clinician Requirements The knowledge requirements of the clinician are the typical starting point for the engineer. The WSN is often a solution to a research or clinical knowledge gap; it gathers and analyses data that the clinician interprets to fill the knowledge gap. The clinician will be aware of the medical aspects of his or her knowledge requirement, and may also be familiar with possible technology-based approaches to meeting it. The clinician, the engineer, and other members of the team may collaborate in the creation of a clinical requirements document or CRD. The CRD describes the medical background to the project, its clinical aims, the experimental protocols to be followed, the data to be collected, environmental factors, and so forth. The CRD may address the following topics: • •

• •

•

3.2.1

What data is to be collected by the WSN solution? What information should be generated by the network, following aggregation and analysis? What level of adjustability by the clinician is required? How should the system interact with the patient (subject), in terms of user interface and feedback mechanism? What are the properties of the deployment environment? Data to Be Collected

The first topic to be considered is the nature of the data to be collected. The following questions should be considered early in the design process: •

• •

• •

•

3.2.2

What needs to be measured (e.g., motion, time-on-task, stress, room temperature, daily log)? How often does it need to be measured (e.g., every second, once an hour)? What activities will subjects be engaging in during data collection (e.g., talking on the phone, watching TV, walking outdoors)? Is the time of day critical in the data collection? Will the type of data needed to be collected depend on other data or other prescribed variables (e.g., collect movement data only when the subject first stands up from the phone)? How much can/should the subject be aware of the measurement system (e.g., fully aware, I want them to perform a particular action; partially aware, they can be wearing or carrying a sensor; completely unaware, the measurement must be embedded in the environment)? Information Reporting

Once the data has been collected, consideration should be given to how the data is analyzed. This is closely linked to the underlying clinical questions that the WSN is addressing. The following questions may be considered:

3.2 Clinician Requirements

•

• • •

47

What information would you like to get from these measurements (e.g., variability of gait, sudden change in stress, lack of alertness)? Does this information need to be customized to the individual? How much information should be gathered (e.g., real-time, hourly, daily)? Do you need proactive alerts based on data gathered? What should these alerts signal?

If the WSN solution is to be adjustable over time by the clinician, it is important to know what aspects or parameters of the solution should be accessible for adjustment. •

•

3.2.3

What kind of parameters would you like to be able to adjust (e.g., which data source to view, sensitivity of measurement, method of viewing)? How should these parameters be accessed (e.g., locally, over the Internet, by the patient)? Subject Interaction

Actuation or interaction with the end user occurs where the WSN provides feedback to encourage activities that lead to a safer lifestyle. Examples of such feedback could be enhancing levels of alertness while driving, or reminding the patient to take medication. When planning the actuation, the following questions should be considered: • •

• •

•

•

3.2.4

What kind of information would you like reported to the subject? Do new interactions have to be created (e.g., the subject needs to answer questions on a computer, the subject needs to respond to a particular sound)? What should trigger each actuation? Should actuations change in response to further information (e.g., if the user does not respond to an actuation within a given timeframe, should a more vigorous actuation occur)? What alerts or events need to be created (e.g., automated alerts sent to a neighbor or caregiver when medication has not been taken as scheduled; body worn vibro-tactile stimulus devices, which provide an indication via the skin when the alertness level drops below a safe threshold)? What impact does this have on form factor and on the nature of the user interface? Is a screen needed, or an audio output, for example? Environment

The physical environment in which the WSN solution is to be deployed must be fully understood. When the network is to be installed in a home environment, the configuration of the dwelling, the building materials, ambient sources of radiation and other sources of interference must be taken into account. If the environment will vary significantly (e.g., includes both indoor and outdoor environments), this may impact on the choice of technology. The following questions should be considered:

48

Informing Your Design

• • • • • •

•

3.2.5

Is the monitored activity restricted to a single location? Is the environment indoor, outdoor, or both? Is there consistent mobile phone coverage (if relevant)? What is the layout of the dwelling? What building materials are used? Are there other aspects of the dwelling that can impact on wireless communications (e.g., does it cover multiple floors of a building)? Are there other sources of radio waves (e.g., microwave ovens, WiFi networks) that can interfere with some communications? Sample CRD Contents

A sample clinical requirements document may contain the following sections: Introduction and scene setting, including medical background

Clinical hypothesis—the question which is to be answered or addressed using technology. Aim—the research aim: what is being investigated and evaluated; this is a more detailed or specific version of the clinical hypothesis. Methodology—this describes the manner in which the experiment may be carried out. It may include: • • •

•

•

•

•

• • •

•

Inclusion criteria and recruitment information—who the subject(s) is/are. Protocol—the manner in which the trial may be carried out. Parameters required—the information to be collected at each step of the protocol and the resolution (e.g., how often the data is collected, the frequency of sensor data sampling). Any other data sets—information about any other data that must be collected at the same time, or events that trigger data collection (e.g., waking, standing). User activity—what the user should be doing during the experiment (lying down, walking, watching TV, interacting directly with the technology). User awareness—how aware should the user be that the experiment is taking place (this may range from unaware, as with environmental sensors, to fully aware, as in actively focusing on the use of a device). Actuation—information on how the system responds actively to the user (if appropriate). Suggested equipment. Specification for how data should be stored and managed. Information about the involvement of any third parties (e.g., alerts to caregivers). Specification for the visualization/presentation of experimental output. This may include real-time data and longer-term trending data.

3.3 End User Modeling

•

49

Future work—some ideas about where the research could go next, so that the solution is open to supporting them.

While the clinical requirements document may provide a good deal of technical detail, it remains the responsibility of the engineer, working with the end user requirements team (ethnographers, interaction designers, etc.) to translate the requirements into a technological design. The clinician may (and often will) identify the optimum way to meet the knowledge requirement; however, the possibility exists that there are other and better/simpler/cheaper/more reliable ways to do so. Of course, such alternative approaches will need to be agreed with the clinician. See Section 3.8 for an example.

3.3

End User Modeling The end user is the patient or subject who is being monitored and supported by the WSN solution. In order to ensure that the solution is acceptable and usable by the user, the engineer must endeavor to “get under the skin” of the end user. In capturing the end user requirements for the system there are three key steps. 1.

2.

3.

3.3.1

Clarify who will use the system and discover their goals (user definition). Describe the human context (people, social environment, goals, problems, motivations). If you understand your user base and what makes them tick, the likelihood of totally missing the mark in terms of user acceptance is greatly reduced. A grasp of the day-to-day activities and contexts of the user will be very informative. Define the users’ experience of the system (usage modeling). Consider the system in terms of the user experience. How does the system fit into the day-to-day activities of the user? Seek to embed the system seamlessly in the user lifestyle; this will increase the likelihood of acceptance and longterm use. Identify the goals that the system will satisfy. Ensure that this satisfaction of the user goals can be clearly verified. Derive system requirements. Transform the usage-based description of the system into a technical description containing system requirements that are consumable by engineers and development teams. User Definition: The Role of Ethnography

The most critical output of the user requirements capture process will be a comprehensive and well grounded understanding of the users of an intended product or system. A key source for such understanding is ethnographic observation. The user definition process will address questions such as: • • • • •

Who are these people we are designing for? What are their lifestyles, their routines, their priorities? What are their concerns? What needs do they have? What is their outlook on their current circumstances?

50

Informing Your Design

3.3.2

Ethnographic Modeling

If the solution is to be a success in the long term, it must fit seamlessly and unobtrusively into the patient’s lifestyle. This means that the designer of the system must have a good understanding of this lifestyle and of the constraints, priorities, routines, and activities that define it. Ethnographic observation can help to establish a model of the patient’s lifestyle that can inform the designer. 3.3.2.1

What Is Ethnography?

Ethnography is an applied anthropological discipline that uses observation to gain insight into how people live and why they live the way they do. This observation may be passive, with the ethnographer not interacting with the subject, or it may be active, with the ethnographer sharing the activities of the subject, in order to better understand them. While ethnography employs interviews and conversation to inform its understanding of the subject, it also relies extensively on the ethnographer’s ability to perceive the manner and causes of the subject’s day to day life decisions and activities. Based on this perception, an ethnographer can work with technologists to identify and design technological interventions which have the potential to improve quality of life and to enjoy long-term adoption by the subject. Ethnography informs the design and development process. The aim of ethnography is to uncover needs that can be designed for by understanding the interplay between people, their environments, and the beliefs, practices, and philosophies that shape the way they act. Whereas a market research focus group tends to focus on people’s perceptions of what they do and their needs, ethnography can deliver a more incisive view of human behavior and experience. 3.3.2.2

Ethnography for Design

Ethnographic fieldwork consists primarily of observation and interview. Anthropologist Michael Agar [1] refers to fieldwork as a funnel through which the ethnographer moves. In the early period of study the focus is wide and the researcher is open to a very broad set of ideas about the meaning of what he or she is experiencing. Over time, goals sharpen and research activities are more sharply defined as knowledge develops. At this stage, the collection of specific bodies of material is useful (such as household surveys, maps of the local neighborhood, and plans of the home environment). The ethnographer becomes more proactive, identifying information to be gathered that will inform his or her research, and engaging in interviews with subjects. The core method of ethnography, and its defining characteristic as a research practice, is participant observation. Such observation begins by analyzing what British anthropologist Audrey Richards called “speech in action” [2] and involves the researcher adopting, simultaneously, the position of cultural insider and outsider. As an insider, the researcher attempts to assist or involves himself or herself in the same tasks as the subject they are studying. As an outsider, the researcher attempts to make sense of what he or she is seeing and experiencing—to make meaning of the life-world they are observing from the perspective of their subject, using their anthropological training.

3.3 End User Modeling

51

As meaning starts to emerge through participant observation, the researcher may begin to conduct interviews (semistructured or more formal). This marks the point at which the researcher leads the encounter rather than allowing the subject’s agenda to dominate. Interviews may also be conducted with a subject’s coworkers, family, or friends as part of an ethnographic study. In healthcare studies, one of the benefits of an ethnographic approach is the possibility for a researcher to simultaneously investigate the beliefs, practices, and ideas of an individual and their caregivers (both formal and informal), therapists, and others, which relate to the topic under investigation. Ethnographers and cultural anthropologists have long acknowledged that ethnographic research produces knowledge of a different nature to that of other scientific enterprises. The nature of ethnographic research—with a researcher collecting data about people’s lives through the use of themselves as primary research instrument—makes field studies highly interpretive and yields nonreproducible results. As a result, ethnographers need to be cautious about the claims they make for the material produced by their primary research and to stress that their work represents “situated knowledge.” It is advisable for them to cross references and support that material with survey or other quantitative research data and market analysis. This allows them to present arguments of a more generalizable and applicable nature. Since ethnographic research involves close personal contact with people, and researchers probe deeply into the lives of their subjects, privacy concerns should be addressed at the outset of a research study. Various professional bodies have issued statements on professional ethics that act either as guides or in a more binding manner. For example, the American Anthropological Association’s statement on professional ethics [3] is considered standard for ethical ethnographic research. Additionally, market research associations [4] have developed codes of conduct that incorporate the needs of researchers (and their subjects) involved in ethnographic research projects. Significantly, these codes can display more awareness of the legal frameworks in which such research operates, such as data protection acts. However, both forms of guidelines are designed to ensure that the privacy and dignity of individuals is maintained and that no harm is caused to them during the research process. 3.3.3

Ethnography: Conclusion

The use of ethnographic observation delivers significant benefits during the requirements capture phase. When designing a technology solution that will be deployed over an extended period in the homes of older persons, it is critical that the technology has the minimum impact. Where the technology aims to actively help the older person (e.g., by delivering a reminder to take medication), then the manner in which this actuation occurs must be effective without compromising dignity or privacy. If the solution fails to meet these criteria it is unlikely to be used in the longer term. Ethnography helps the designer of the technology to understand the lifestyle of the end user, and acts as a voice of the user during the design process. The insight provided by ethnography can make the difference between a solution that solves a problem neatly and one that misses the mark.

52

Informing Your Design

For optimum results, ethnography should be combined with other user requirements capture techniques, such as surveys.

3.4

Usage Modeling Usage models are established by examining a technology solution from the perspective of the subjects who are to use the system. Such models provide significant feedback into the usability of a device or system and its suitability for achieving the purpose for which it was created. Having understood the users and their contexts, for example through the application of ethnography, the next phase involves describing their experience of the system, or “usage.” Usage is how the user interacts with a system to get some desired result. Descriptions of usage should include a description of: • • • • • • •

What the user was trying to achieve when interacting with the system? The manner in which the system was used to achieve this goal? How often does an interaction takes place? What is the importance of the interaction succeeding in achieving its goal? How easy can the goal be achieved? What are the confidence levels of success? Barriers or obstacles to the successful interaction.

Usage modeling is important for a variety of reasons. First, it leads to new product requirements and design constraints that would have been missed otherwise. Second, well constructed usage descriptions can overcome the designers’ own experience bias (i.e., what we would do). Third, it leads to the design of systems that adapt to the user’s life, rather than attempting to adapt the user’s life to the system. Ultimately, usage models are important because if you don’t know how the system will be used, you can’t know whether you have the right requirements. 3.4.1

The Usage Modeling Process

A typical usage modeling team may consist of ethnographers, clinicians, end users, product engineers, software engineers, hardware engineers, and user experience or human factors experts. The process begins by defining the problem domain or the issue that is to be solved. For example, elders who live alone are often seen in the emergency room due to dehydration from lack of fluid intake. From this problem statement the team gathers quantitative data on the impact of the problem and on the reasons (e.g., why elders are not consuming fluids as they should). The team may find that the elders are forgetting to drink enough fluids due to preoccupation or depression (this is quite a common reason). Using the quantifiable data combined with ethnographic qualitative data the team constructs a series of personas (see sidebar). The personas are hypothetical typical elders suffering from dehydration. The team may also consider other actors in the life of the persona, such as family members, nursing staff, sensor installers, and call center personnel. They may

3.4 Usage Modeling

53

Sidebar: Personas One useful product of this phase of a study can be personas. Personas can be defined as hypothetical archetypes of actual users. Although they are fictional, they are based on ethnographic research and on existing demographic or segmentation research that allows the numerical importance of particular user groups to be understood. Personas are descriptions of user types that are defined with rigor and precision, and they are believable since they have a name, a face, personal details, and skills. Personas are differentiated by their goals, needs, and desires and are described within their social, physical, and environmental context. Personas codify research in a way that is consumable and actionable by a team that might not have either experienced, or be aware of, the user types that they are designing a system for. As such they can unite people from very different disciplines. Personas eliminate elasticity within the user description in a way that resists distortion by team members. Looking beyond design and implementation to subsequent validation and feedback, personas can act as the profiles for recruiting real people to participate in such trials.

choose to create personas for each of these actors, in order to document the assumptions about them which are reflected in the system design. Once the short descriptions of the personas are created, the team maps out the course of the persona’s day. The map of the day begins with rising from bed and continues through to the next day. The team may model several types of days, including weekends where habits may be different than weekdays. Once these typical habits are mapped out, opportunities are identified for the interjection of sensing and feedback (actuation) into the day. These represent usage opportunities. For each such usage opportunity the team may consider: • • • •

• •

•

• •

The goal of the end user; The role of the system in helping the end user to meet his or her goal; The importance of the system in the overall achievement of the user goal; The criticality of success (how important is it that the user achieves his or her goal?); Potential causes of failure in the user interaction; Characteristics of the system that can increase the likelihood of success (e.g., for an actuator, a louder beep, repeated user prompts, brighter flashing lights); Whether other information about the user can be inferred from the interaction; What might cause false alarms; How to avoid such false alarms.

54

Informing Your Design

To return to the example of the dehydrated elderly patient, we may consider placing motion sensors above the sink and refrigerator. If we collectively sum all of the motion in the kitchen for a 24-hour period as well as how many times that the refrigerator door opens, and keep track of that on a daily basis, we may find a correlation between reduced activity in the kitchen and a likelihood of dehydration. Clearly there may be many reasons for reduced kitchen activity (e.g., the elder traveling for holidays), but this may still represent a first cut at predicting the onset of dehydration. Using an actuator in another room, asking the patient questions about activity outside the home or about visitors bringing food and drink may help to reduce the number of false alarms. The same actuator or display may prompt the patient to drink more when the system infers they may need to. 3.4.2

Benefits of Usage Modeling

For the designer of a WSN, usage modeling can deliver some important benefits: •

•

•

•

3.5

The design aims to serve the user, rather than simply to deliver functional technology; The involvement of all stakeholders in the modeling team decreases the likelihood that the system will not find favor with end users; Analysis of the role of the system in meeting a user requirement increases the focus on end-user success, rather than technology success; Simplicity and usability are encouraged.

Requirements Looking at usage in terms of the environment in which a system will be deployed (type of domestic residence), and the use cases or scenarios for its use, provides the design team with a series of requirements for their system. These requirements can range from the functional to the nonfunctional. Functional requirements clarify what the system does and are typically measured in “Yes/No” terms. Nonfunctional requirements refer to issues of quality (performance, reliability, etc.), to constraints, to the ideal user interface and other factors that are not measured in terms of a simple “Yes/No.” Nonfunctional requirements often refer to the qualitative or experiential aspects of a system and how it will be used or experienced. Requirements help establish a clear and common understanding of what the system must accomplish, expressed in terms which are unambiguous, complete, consistent, and concise. All system stakeholders must share the same understanding. Requirements are the foundation on which systems are built. 3.5.1

Use Cases

Use cases may be an appropriate way to describe the requirements of the system, particularly where the interaction of the system with clinician, subjects, or other users is concerned. The use cases are simple, short, and succinct descriptions of the manner in which the system behaves in particular sets of circumstances. The use

3.6 Failure Modes and Effects Analysis

55

cases may describe any functionality of the system, from the sensing of end-user behavior to the creation of reports. Use case creation and refinement is typically an iterative process, and the result of ongoing dialogue between all members of the team. A use case may include: 1. 2. 3. 4. 5. 6.

A use case identifier; A use case title; A summary of the circumstance and the expected activity or response; Any extensions or changes in the use case (because use cases are requirements, they can and do evolve); The user involved (e.g., clinician, subject); The use case author, date, and version.

Note that there is a significant emphasis on version control, authoring, identification, and similar administrative details. This reflects the fact that requirements and expectations change during the lifetime of the project, and it is essential to maintain current and correct requirements and use cases. Use cases can usefully be redeployed as the basis for the test plans outlined in Chapter 6.

3.6

Failure Modes and Effects Analysis Failure modes and effects analysis (FMEA), is a process by which potential failures in an experimental or process design can be identified before they actually occur. Effects analysis predicts the gravity of each failure. In short, FMEA provides risk assessment. In healthcare, experimentation usually includes human subjects, and doing FMEA at some level will help to provide a better level of patient safety.

Example of a Use Case Description Use Case ID:

Use Case Name: In-trial subject movement

Summary: Describes how subject will move during the trial

Extensions: Users: Clinician, Subject

Author:……….. Date:……… Version: ……. Sit-to-Stand Trial For the sit-to-stand trial, a chair will be placed at on one of the walkway extensions such that the subjects feet are on the mat (see Figure 3.1). The subject will stand up, walk along the mat, turn before reaching the end of the mat, and walk back along the mat.

56

Informing Your Design

Walkway Extension #2

Figure 3.1

Floormat

Walkway Extension #1

Sit-to-stand trial.

The first step in the FMEA process is to identify any errors, problems, or defects that may occur that may occur in both procedure and equipment during a process. Every member of the team doing the experiment should be involved, including those who developed any specialized methods or tools used. For each possible failure mode, three factors are considered: 1. 2. 3.

The probability that a failure may happen; The severity of the consequences of a failure; How easy it is to detect the failure.

Each factor is allocated a numerical value between 1 and 10. These values are then multiplied together to produce a composite index, or risk priority number (RPN). Failure modes are then ranked in order of RPN. Those with the highest RPN values are addressed as a priority during the design phases of the experiment, thus improving the likelihood that the experiment will go according to plan. 3.6.1

FMEA Example #1

An experiment will collect kinematics data from a group of human subjects to determine progress in a physical therapy program. Each subject must wear a wireless sensor on each limb while walking. Each sensor will use a radio to transmit accelerometer data to a laptop. All members of the team took part in failure modes analysis, and a table of two predictable failure modes was drawn up (Table 3.1). In Table 3.1, the RPN index is clearly higher for transmission interruption than it is for low-power shutdown. This allowed the team to identify transmission interruption as the key issue to be addressed at design time. As a result the designer may consider writing firmware that maintains the data integrity on the device until assure data transmission is completed. 3.6.2

FMEA Example #2

Another example where FMEA was used relates to the design of an experiment attempting to determine why subjects fail to take their medication on time. In this

3.6 Failure Modes and Effects Analysis

57

Table 3.1 Source

Failure Condition

Potential Cause

Effect

Index*

P

S

D

RPN

Comment

Battery

Lowpower shutdown

Failure to replace

Data loss

1

10

8

80

Return sensor to charging station

Radio

Transmission interruption

RF interference

Data loss

3

9

9

243

Shutdown cordless phones; redundant storage to flash

*

1=low, 10=high. P=probability, S=severity, D=detectable, RPN=P×S×D

example, in the planning process the team developed the following hypothesis, “There is a relationship between morning patterns of activity and the likelihood of taking medications on time.” Since there may be many reasons for nonadherence to a medication regime, a decision was made during the planning stage to use FMEA to identify the five most likely reasons for not taking medication according to regimen. For FMEA purposes, the failure condition was defined to be nontaking of medication. The level of severity was agreed to be the same for all five reasons, since there is only a single failure mode, and the health impact of not taking the medication is a constant. The first step was the consideration of how to weight the probabilities of failure occurrence. For example, in the scenario that medication was missed due to disruption of the morning routine by an unexpected visitor, a table was constructed (Table 3.2). The occurrence categories were bracketed based upon previous studies of morning behaviors of typical subjects considered for the project. Once each of these probabilities of occurrence was identified, a ranking based on previous experiences of detection methods was made. Another table was then created for the detectability value (Table 3.3). Using likelihood-of-occurrence ranking tables, previous experience, published literature, and the detectability rankings table, an FMEA model for nonadherence to morning medication regimes was constructed as in Table 3.4.

Table 3.2 Level

Probability of Effect

Rank

Occurrences

Failure is unlikely

1

<3 visitors / 60 days

Low

Relatively few time

2

<5 visitors / 60 days

Moderate

Occasionally

3

<7 visitors / 60 days

High

Repeated

4

<12 visitors / 60 days

Very high

Failure is certain

5

<75 visitors / 60 days

Visitors (with in an hour of first motion) Remote

58

Informing Your Design Table 3.3 Level

Likelihood to detect the effect in the time

Rank

Remote

Sensor saw this once

1

Low

Sensor system might catch this mode

2

Moderate

Sensor system may show this mode

3

High

Sensor system will show this mode

4

Very high

Sensor system will absolutely show this mode

5

Table 3.4 Failure Mode

Root Cause

P

D

RPN

Change in the complexity of daily routines (too busy)

Visitors

4

3

12

Phone calls

3

4

12

Early appointments

3

4

12

TV

3

3

9

Family or caregiver illness

2

1

2

Distraction in the kitchen

4

3

12

Medication change

1

1

1

Disease

4

1

4

Medication Not of Value

3

1

3

Cognitive Impairment

2

3

6

Medication change

1

1

3

Travel

5

3

15

Hospital

3

3

9

Travel

5

3

15

Lost medication

1

4

4

Hospital

3

3

9

Personal illness and attitudes (could be a confound)

Not remembering Environmental change Not with medication

P=probability, S=severity, D=detectable, RPN=P×S×D

Using the FMEA approach, the top five reasons were extracted using their RSP values. The top five reasons were then considered by the engineering team and procedures for detecting these events were identified. 1.

2. 3.

Travel. Can be detected by the subject wearing a tagged badge. Travel is assumed if the tagged badge does not send a signal to a home-based detector for over 24 hours. This is confirmed by lack of activity reported by home-based motion sensors, and the absence of telephone use. Visitors. Can be detected by the door opening and by a higher-than-usual amount of motion detected by home sensors. Phone calls. Detection of phone on or off hook.

3.7 Conclusion

4. 5.

59

Early appointments. Detection of badge not present followed by no motion. Distractions from the kitchen. Detection of using fridge and sink to detect greater morning activity in the kitchen.

After the FMEA was conducted, design work began on the system architecture and the software development for the medication reminding system. In parallel to the system design and development a probe study was conducted by Lundell et al. [5]. In the probe study of existing medication reminding systems, the authors documented the reasons again for nonadherence to the morning medication regime. In the study the 10 subjects tested were asked to write down whether the missed dosage event was a normal event or a nonroutine event. Table 3.5 shows a breakdown of “no, not normal,” “yes, normal,” or no response, which was used to validate the FMEA process done. The results from the small probe study aligned well with the FMEA results. Having completed this analysis, the next step was to develop a system that uses awareness of the users’ activity and location to prompt them when they are in the vicinity of their medication. A series of devices and sensors has been developed to address this issue in the home. Working together, these devices allow the system to prompt only if the user has indeed forgotten the medication and only when they are close to the medication box. The devices also maximize the chance that the reminder will be seen and acted upon. The system developed for medication adherence is discussed in detail in Chapter 8.

3.7

Conclusion •

•

In many ways, the engineer acts as a supplier of technology to the clinician, in consultation with end users, ethnographers, and so forth. The clinician typically sets the goals for the WSN solution, using a clinical requirements document (CRD). The engineer will usually take this as a starting point, and then inform himself or herself and the resulting solution further by considering the brief from the user’s point of view. Having a strong grasp of the user requirements is a prerequisite for design. Ethnography offers a very promising technology for developing a deep understanding of the end user and his or her context. This helps to avoid the possiTable 3.5

Probe Study Results of Reasons for Nonadherence

Reason

No

Travel without medication

2

Morning Visitors

3

Early appointments

1

Illness

1

N/A 2

1

Watching TV Slept in

Yes

2

1

60

Informing Your Design

•

•

•

3.8

bility of designing and developing a solution that does not meet the user’s requirements. Ethnography can be combined with usage modeling to create a well-informed design. An important cause of problems over the longer term is failure by end user to adopt or persist with the solution. In order to minimize the likelihood of the user rejecting a solution over the longer term, the design process may use usage modeling to inform the technology and design decisions. The design requirements must be documented, in order for them to be agreed by the full team, and also to facilitate implementation and testing. Use cases are a convenient tool to describe many requirements. The combination of clinical requirements and user-centric design and analysis equips the engineer well to design his solution. Established methods exist for assessing the likelihood and the severity of failure modes. Using techniques such as FMEA can provide valuable input to the specification and design processes for any WSN project.

Field Experience: Furniture Cruising An example of requirements capture highlights the value of ethnographic observation of the end user. The clinician in a particular project sought to identify indicators for subjects being most vulnerable to falling. Clinical research has shown that good indicators of falls include variations in speed, variations in stride length and width, postural swaying, and variations in distribution of pressure across the foot. A high-technology approach involving gait monitoring with combined cameras and sensors was outlined in the CRD. Such an approach allowed lab-based capture of several key gait characteristics. However, ethnographic observation showed that subjects acted quite differently in the home, compared to the lab. In particular, subjects hold onto furniture (or “furniture cruise”) as they navigate their homes, using the corners of tables, backs of couches, edges of doors, and so forth as a sort of handrail to ensure balance. Increased sensations of instability on the part of the subject led to more regular use of the furniture for support. It also led to greater pressure being placed on the furniture, as the subjects tended to lean upon it to a greater degree. The ethnography team suggested that simple touch sensors at key navigation points (e.g., corners of tables and couches) could track the frequency of furniture surfing and the amount of pressure applied to the sensors. This approach was simpler, less costly, and more rapid to deploy. It reflected the home reality, rather than the setup in the laboratory. It also compromised the privacy of the end users to a lesser extent, since no video was required. No wearable sensors were needed, thus increasing the reliability of the system, which was otherwise vulnerable to changes of clothing, dropping of the sensor devices, and so forth.

3.8 Field Experience: Furniture Cruising

61

References [1] [2] [3] [4] [5]

Agar, M., The Professional Stranger: An Informal Introduction to Ethnography, Academic Press, Orlando, FL, 1980. Sanjek, R., “The Ethnographic Present,” in Man, New Series, Vol. 26, No. 4, 1991, pp. 609–628. American Anthropological Association, Statements on Ethics, “Principles of Professional Responsibility,” http://www.aaanet.org/stmts/ethstmnt.htm. “The Code of Conduct of the Market Research Society,” http://www.mrs.org.uk/standards/codeconduct.htm. Lundell J., T. L. Hayes, and S. Vurgun,et al., “Continuous Activity Monitoring and Intelligent Contextual Prompting to Improve Medication Adherence,” 29th Annual International Conference of the IEEE Engineering in Medicine and Biology Society, Lyon, France, August 23–26, 2007.

Select Bibliography Alder, P. S., T. A. Winogard, Usability Turning Technologies in Tools, New York: Oxford University Press. 1992, pp. 44–187. Clarkson, J., R. Coleman, and I. Hosking, et al., Inclusive Design Toolkit. Cambridge: ESPRC, 2007. Hutchinson, H., et al., “Technology Probes: Inspiring Design for and with Families,” Proc ACM CHI 2003, Vol. 1, pp. 17–24. Lambert, H., and C. McKevitt, “Anthropology in Health Research: From Qualitative Methods to Multidisciplinarity,” British Medical Journal, Vol. 325, 2002, pp. 210–213. O’Mullane, B., B. Knapp, “MOBIUS Platform Requirements,” http://www. trilcentreintranet.org/, Nov. 2006.

CHAPTER 4

Technology Selection 4.1

Introduction This chapter looks at how to architect and build a sensor network solution that addresses a particular clinical research need. The sensor network is made up of a combination of technologies that collect data about patient activity and analyze this data to extract clinical knowledge and/or validate a research hypothesis [1–7]. These technologies include: • • •

Hardware; Firmware; Software.

Each element in the technology mix must be selected carefully, in order to ensure that the overall technology solution is a best fit for the problem domain, as explored in Chapter 3. The chapter concludes with some examples of relevant field experience.

4.2

Practical Guidelines for Architecting WSN Solutions for Healthcare What differentiates healthcare from other WSN technology application is the criticality of reliable data transmissions. In wireless communication of patient data, several concerns may arise about the potential effects of RF wireless technology in and around medical devices. These concerns relate to the ability of the devices to function properly and the resultant impact on the safety of patients and operators. In all stages of the solution development and product life cycle the engineer should implement best design practices as recommended by the governing regulatory body in the country of application. In general these practices include, but are not limited to identification, documentation, and implementation of product design requirements, design verification and validation, risk management processes and procedures. At the onset of the design a team should establish a collection of procedures to control the design and development of healthcare devices and system, to ensure that specified design requirements are met. As the design progresses the documentation should be updated to continually update the risk analysis throughout the design and development process as more information becomes available. The results of the risk analysis updates should be used to continually refine the design specification and system architecture.

63

64

Technology Selection

Having collected all available information, the engineer must now draw up functional and technical architectures for the WSN solution. At this stage, a range of new factors must be considered, not just technological but also regulatory, user-centered and policy-based. The most important of these include: • • • • • • • • • •

Cost; Scalability; Fault tolerance; Localization; Routing; Wireless regulatory issues; Energy efficiency; Medical regulatory issues; Long-term usability; Privacy and security.

Each of these is considered here. The interpretation and implementation of these guidelines will vary from project to project. 4.2.1

Generalized WSN Architecture for Healthcare

Figure 4.1 shows a generalized WSN architecture for healthcare. While this does not illustrate any particular system, it shows the classes of components and their relationships with one another.

(WBASN) Tier 1

Data aggregation Tier 2

Communications (Internet, 3G etc.) Tier 3 Medical IT systems GPRS/3G Healthcare professional

Bluetooth/ 802.15.4

Wireless body sensor network (WBSN) Smart phone

Primary care/ hospital facilities

Users

WiFI

Family/informal caregiver

Figure 4.1

Generalized WSN architecture for healthcare.

4.2 Practical Guidelines for Architecting WSN Solutions for Healthcare

•

•

•

65

At the core of the system is the user, also referred to as the “subject” (in a research environment) and as the “patient” (in a clinical or therapeutic environment). The user is monitored by sensors and prompted by actuators, within wireless body area sensor network or WBASN. This is referred to as Tier 1. The information gathered by the components of the WBASN is sent to an aggregator (often a PC or a smart phone), or personal server (PC). This is referred to as Tier 2. The communications links used between the WBASN and the personal server will vary according to circumstances; in the diagram three are shown (ZigBee, Bluetooth, WiFi). The personal server connects over the internet and/or GPRS and/or other long range communications protocols to various Tier 3 services. These may include a medical server, a healthcare provider, a researcher, a caregiver, emergency services, and so forth. Again, a range of communications protocols are possible here, depending on the requirements of the particular problem domain.

Of the three tiers discussed here, this book focuses most on Tier 1. The direct engineering input required for Tiers 2 and 3 is less than for Tier 1; most solutions use PCs and smart phones and the Internet; the technical challenges of providing healthcare applications on these platforms are similar to those faced by other applications. 4.2.2

Literature Highlights: Architectural Models

Several architectural models for WSN have been described in the literature. Hristozov [8] includes cost, scalability, fault tolerance, localization, routing, regulatory, and energy efficiency. In addition, particular attention should also be given to medical regulatory, long-term user exposure, privacy, and security. Ramamurthy [9] views the wireless sensor network system as an open/closed loop control system formed by using sensors and actuators, with the objective of controlling certain state parameters of the system. In this definition of a WSN the user is as much a part of the system as the technology which is being developed. Other system elements include how the components of the system converse, the amount of fault tolerance and reliability of the system, the physical technology, storage elements, data retention policies, predictive maintenance and watchdog mechanisms in the system. Cost: Each element in the design of the system carries with it a sensitivity to cost, particularly in scenarios where many such elements are needed. For example, the use of a light sensor to detect the presence of a person in a room may be quite inexpensive. However, rolling out this solution in a large facility with hundreds of rooms and patients may become rather expensive. Scalability: An attractive aspect of most WSN systems is the flexibility to use as many nodes as necessary in various configurations. However, when the numbers of nodes in the system increases, the radio frequency bandwidth may become clogged,

66

Technology Selection

resulting in system latencies or data loss. The size of the network also impacts on the maintenance of the system and the ability to diagnose failures. Fault Tolerance: For healthcare applications, the data being transmitted in the system is often critical and must be prioritized to ensure proper medical care. Wireless sensor networks offer a “best effort” delivery of data delivery service but do not explicitly provide transmission verification methods for critical data. It may be necessary to provide higher-level error correction and data validation functionality. In addition, the system should be aware when sensors or actuators are missing and should respond when expected data is not received. Location: In clinical and institutional settings, the location of sensors and actuators may be chosen to reflect user needs or the physical constraints of an architecture. Some systems, for example those collecting and analyzing environmental information, require the system to know the location of the sensors and actuators to best interpret the data coming from them. Other considerations of the location include the RF wireless emissions from one product or device can affect the function of another, how electromagnetic environments where medical devices are used may contain many sources of RF energy and the use of RF wireless technology in and around medical devices is increasing. Routing: Similarly to location, the routing of data across the network, particularly via RF, must be carefully considered. The routing of data not only impacts the reliability, fault tolerance, and scalability of a system but also the energy required by the system to communicate data. The ideal approach is to keep the routing to a minimum and to transmit via radio only when absolutely necessary. Wireless regulatory: Depending on the WSN system application, architects of the system must use great care in choosing the communication frequency. In most cases, the choice is limited to those portions of the spectrum that allow license-free operation. Energy efficiency: One reason that healthcare systems architects are attracted to WSNs is that many sensors do not require external power. As such, at least some devices in the system rely on battery power or renewable sources such as solar panels. Systems software and firmware solutions exist which, when combined with energy efficient hardware, allow devices to go into low power modes or be shut off when not in use. Medical regulatory: Unlike other applications of WSN technology, medical regulatory issues impact not only the end product but also the very manner in which the system is designed. Appropriate design practices should comply with the requirements of the local applicable medical legislation and regulations. Long-term user exposure: Another aspect of WSN systems for healthcare to be considered is the impact on the user of long-term exposure to the materials in the system as well as the energy fields the system may create.

4.3 From Requirements Statement to Technology Selection

67

Privacy and security: Sensors must respect the privacy and security of users, clinical staff, and visitors. The design of a sensor may cause needless privacy concerns on the part of users. For example, the use of a blinking light as a debugging interface on a motion detector may cause a patient to worry that there is a camera in the room. This may occur even though the sensor doesn’t behave anything like a camera. Privacy regulations and laws vary dramatically from country to country. Additionally, if health-related information is displayed by the WSN application, laws like the Health Insurance Portability and Accountability Act (HIPAA) in the United States, and the Data Protection Directive in the EU may cover the information collected and access to it. All of these guidelines apply to the architectural design of WSNs for healthcare. The interpretation and application of these guidelines to every possible solution cannot be covered here; it is up to the architect to apply these guidelines to his or her particular solution design. In some cases, not all the points above will be relevant. As Hristozov [8] states about WSN system choices, “Navigating the proprietary and official standards is difficult, depending on the marketing flavor experiences at some of the web sites. Another difficulty is that different hardware/software solutions are hard to compare, because there is no metric. The best alternative is to rely on common sense and some guiding principles, such as open source versus proprietary code, open communication standard versus one company solution, etc.” That said, some general rules can be provided to guide the choice of hardware, firmware, and software for WSN solutions. This is described next.

4.3

From Requirements Statement to Technology Selection The choice of technologies for wireless sensor networks is broad, with a range of options available across microcontrollers, radios, sensors, operating systems, firmware, and so forth. Selecting the optimum combination of technologies to address a particular healthcare problem is not trivial; this section looks at how to match up a technology solution to a clinical problem. The objective is to select the best technology combination to collect and analyze health-relevant data and to provide feedback as appropriate to the patient, a well as to deliver information to the clinician. In the previous chapter we looked at the following issues: • • • • • • •

User definition (who are we developing for); Usage modeling (what will be the user’s experience of using the system); Technical design constraints; Data to be collected; Information to be extracted from the data; Subject interaction and actuation; The environment in which the WSN solution will be deployed;

Having completed these exploratory steps, the engineer should now have a clear picture of the functional requirements of the WSN solution and the environment in

68

Technology Selection

which it will operate. Key parameters such as the data, the environment, the actuation, the clinician interface, and the behavior being monitored will now be apparent. The engineer can now proceed to identify the most appropriate hardware and software components, and build the solution.

4.4

Hardware Choices As outlined in Chapter 2, there are a wide range of hardware technologies available for WSNs. The choice of hardware must reflect the solution objectives, environment, patients, and so forth. This section provides some insight into correct hardware choice. When selecting the hardware components of the WSN solution, the general systems architecture is broken into the three parts: 1. 2. 3.

The devices, including sensors and/or actuators, embedded processor, and radio; The data aggregator for the WSN; The hardware for the backend data analysis/visualization services (if needed).

In most cases the latter two components are commercially available devices like personal computers, personal digital assistants, computer servers, or cellular phones. These devices typically support communications standards that allow them to communicate with each other as well as with the WSN (sensor) devices. Apart from documenting the choices made and the final testing of these commercial devices, there is usually little detailed hardware design work required at this level. The focus of this section will discuss the choices associated with the physical sensor and/or actuator devices, including the embedded processor and radio. 4.4.1

Selection Criteria

There is a wide range of technology available for WSN devices. This includes a selection of off-the-shelf devices and of modules which can be combined to create new devices. The possibility also exists to create new devices to meet a particular need. When choosing the right device technology for a particular WSN application, the following selection criteria may be considered: • • • • • • • •

Performance; Wireless coexistence; Quality of service; Range; Data integrity; Security; Standards compliance; Power variation immunity.

4.4 Hardware Choices

4.4.1.1

69

Performance

How much data can be transmitted, in what space of time? The requirements for your particular WSN will depend on what data is being collected, and how often. The data transmission rates of different devices vary widely, as described in Chapter 2. Some network configurations can lead to increased latency; this should be taken into account, and addressed if it represents a risk for your WSN application. In general, WSNs for healthcare do not generate very large amounts of data at a time. The exception is where video or other multimedia data is being harvested, or where networks of sensors are cooperating in the collection of real-time data (e.g., a gait system with sensor mat, cameras, and accelerometers/gyroscopic sensors). Sensors for door opening and closing, for room occupation detection, for movement detection, for temperature, and so forth, generate only small amounts of data, either event-driven or periodically. Table 4.1 shows typical data rates for four common choices of radio technology. 4.4.1.2

Wireless Coexistence

Will the devices work alongside other devices both within and beyond the WSN, without interfering with them or being disrupted? The amount of available spectrum is limited, and competition for particular channels may be problematic, as shown in Table 4.2. This is closely linked to the choice of RF wireless technology chosen. Systems outside the WSN are a potential problem here—possible competitors for spectrum include wireless LANs (WiFi), mobile telephones, PDAs, Bluetooth networks, ZigBee networks, wireless modems, and medical systems such as WMTS. Other sources of interference due to sidebands or bleeding include ham radio, microwave ovens, television and radio, large magnets (e.g., speakers), and so forth. 4.4.1.3

Quality of Service

How susceptible is your device to dropped connections, to problems with connection setup, and so forth? For example, if your WSN uses a GSM mobile telephone as an aggregator, and requires real-time data transmission, is there a danger from dropped calls or loss of coverage? If your WSN relies on a mobile telephone to contact a doctor in the event of a medical emergency, this may be impacted by dropped calls, lack of a connection, or loss of coverage.

Table 4.1

Radio Data Rates

Technology

Data Rate

802.15.4

250 Kbps

Bluetooth

1 Mbps

802.11

11 Mbps

UWB

100 Mbps

70

Technology Selection Table 4.2

4.4.1.4

The Crowded Spectrum

Technology

Spectrum

802.15.4 / ZigBee

2.4–2.4835 GHz (world) 902 MHz to 928 MHz (America) 868.3 MHz (Europe)

Bluetooth

2.4–2.4835 GHz

802.11

2.4, 5, and 3.7 GHz (future)

GSM 900 (Europe)

890–915 and 935–960 MHz

GSM 850 (U.S.)

824–849 and 869–894 MHz

GSM 1900 (U.S.)

1850–1910 and 1930–1990 MHz

Wireless modems

2.4–2.4835 GHz 5.725–5.825 and 4.5–4.8 GHz (WiMax)

WMTS

174–216, 470–668, and 450–470 MHz (prior to 2000) 606–614, 1395–1400, and 1429–1432 MHz

Range

The range of successful radio transmission and reception is an important factor in device selection. Range is significantly affected by architectural details such as building layout, construction materials, and construction methods. It is also affected by furniture placement and décor. Body worn sensor ranges are affected by the position on the body and whether the body obstructs the line of RF communications. This is explored in some detail in Chapter 2, but common choices are shown in Table 4.3. Of course, all rages of communication are also supported by wired connection technologies including POTS, ADSL, and cable broadband. 4.4.1.5

Data Integrity

How confident can you be that all the data sent is being received without corruption, and that other spectrum users will not cause drastic changes in performance? Increased competition for a particular wavelength can lead to your data transmission being unexpected slowed. Radio systems that have built-in strategies for reducing interference (e.g., frequency hopping) will be relevant here. 4.4.1.6

Security

Personal data is confidential, and subject to privacy protection legislation. The WSN will need to take this into account; some devices may facilitate data security.

Table 4.3

Radio Ranges

Technology

Range

802.15.4/ZigBee/ Bluetooth

Short-range and home

Bluetooth and 802.11

Near-range

GSM and GPRS

Long-range

4.4 Hardware Choices

4.4.1.7

71

Standards Compliance and Electromagnetic Compatibility

The electromagnetic emissions of the chosen device, and the immunity of the device to the emissions of other technologies, can have an impact on the successful operation of your WSN, as well as its usefulness in an environment with other RF systems nearby. 4.4.1.8

Tolerance for Power Variation

How well does the device respond to surges in voltage or brownouts (if wall-powered), and to low-power situations (if battery-powered or solar-powered). 4.4.2

Relevant Clinical Research

Many studies have been done to determine the actual congestion of ISM bandwidth in the hospitals and clinical settings a few of them include [15, 16, 18]. Most hospital ICT departments will comment on the congestion of their own specific environment and as an engineer in the field one should be aware of the issues associated with the specific installation. As the population continues to purchase cellular phones and PDAs that also use Bluetooth and 802.11 radios for personal applications, when they visit patients they inadvertently add to the congestion in the 2.4 GHz ISM band in the clinical setting. The congestion the general public brings is supplemented by clinical staff using laptops, PDAs, tablets, and cellular phones as part of their existing workflow tools. In the characterizations from Krishnamoorthy [15], they found that there was significant impact to the wireless quality of service for wireless systems around critical locations such as emergency rooms (ERs), intensive care units (ICUs), surgery blocks, and radiology. The authors found that like in the home setting the majority of interference issues and congestion came from microwave ovens in operation and 802.11 contamination. In these studies the authors also found the amount of congestion in the ISM band was a function of the time of day. As expected in the evening and night the usage of the wireless bandwidth dropped significantly as staff and visitors left the environment and general activity was reduced. Another similarity between the clinical and home wireless environment was cited by Lin [17] and Davis et al. [20] where the signal propagation was significantly different between measurements in open field testing of wireless ranges and distances of reliable communication seen in the clinical setting. Lin [17] found that open field predictions tended to overestimate measured fields where the walls were finished with gyprock rooms and along corridors of both gyprock and brick construction. The findings from both the aforementioned reports also witnessed the open field models used for propagation underestimate field levels measured in brick-constructed rooms and in below-ground corridors. The likely reason for the increase in RF propagation is the impact of multipath effects cited early in the book. All studies that examined the impact of the wireless environment as compared to the recommended EMI emissions found that although the environment contained significant EMI congestion there were no emissions above the FDA recommended immunity level of 130 dBpV/m (3 V/m).

72

Technology Selection

In attempting to adjust the wireless packet size to improve quality of service, Gomine [22] conducted studies on the optimization of a wireless three-lead ECG using an IEEE 802.15.4 radio. In the instance where the device was used in isolation the author found that an aggregate data rate of 130% of the capacity from three transmitters leads to a good throughput rate of little more than 50%. As the author introduced 16 other transmitters, the good throughput rate dropped by a factor of 10. To improve the quality of service the author reduced the packet size and repeated the test. With the reduced packet size the good throughput rate for 16 transmitters was 40%, substantially better than before. The offset of reducing the packet size subsequently increases the delay in the ability to access the data from any one of the transmitters. Knowing the environment and the wireless radio used, the engineer can thus adjust the transmission of the data as well as timing of sending the less critical data when the environmental congestion is less. As in any design optimizations there are certainly trade-offs that must be considered between quality of service, amount of data, and the timely access to critical data. 4.4.3

Off-the-Shelf, or Bespoke?

An issue for the network designer to consider is whether an existing hardware solution is available or a custom device needs to be created. If the solution requirements cannot be met by commercially available systems, two options present themselves to the hardware designer: 1. 2.

Use modular integration (e.g., building a device from modules that support processing, sensor, radio, or other functions). Design a new device from the ground up.

In some instances, while modular integration may provide a cost-effective means of designing a prototype, the overall system cost may be high. Apart from the cost of the modules, the engineering team may need to rely on others for technical help to deliver a rapid time to market. This introduces external dependencies for the project. In other instances, a totally new device may need to be created. In such a scenario the architectural team may be pursuing unique product features and intellectual property. In choosing this design route the risks for scheduled delivery and efforts required for the engineering team may be higher. 4.4.4

Two-Chip or Single-Chip?

Many designs, both modular and bespoke, are based on combining two embedded processor chips, often with different manufacturers or classifications. In some of these designs, one processor controls the RF functionality, while the other acquires the data and passes messages through serial lines to the first. This design configuration has the advantage of good power regulation and control, but may suffer a higher hardware cost in the end. In a two-chip architecture the embedded devices often communication through universal asynchronous receive-transmit (UART)

4.4 Hardware Choices

73

protocol, CAN, or through a simple serial connection. Figure 4.2 shows a schematic of a two-chip architecture. Alternatively, the device architecture may contain only one embedded processor as in the example in Figure 4.3. When choosing between a two-chip and a single-chip approach, consideration should be given to how the hardware design satisfies the system architect, usage model constraints, environmental concerns, and regulatory issues. 4.4.5

Documentation Is Essential: The PDRD

Documenting the full system design process, from requirements capture to final test, is important in any project. It protects the project against changes in personnel, it ensures shared clarity of vision across all stakeholders, and it provides explanation and assistance to engineers who may need to modify or replicate the system in the future. To document the design requirements and constraints together with the hardware design, a prototype definition and requirements document (PDRD) may be used. The purpose of the PDRD is to capture, in a change-controlled document, the definition, requirements, design assumptions, and hardware selection, throughout the design process. An example PDRD format consists of the following elements. The exclusion of some elements and the addition of others may be appropriate, depending on the details of the project. Example PDRD sections: A title page with engineers, prototype name, project name, group, approvers, and revision editors of the document.

Or another RF device

UAR T

Either/Or

Embedded Embedded Processor processor

I2C

Sensing or Actuating actuating device Device (e.g. BP, (e.g., BP,heartbeat, heartbeat, ADC magnetic switch, etc.) etc)

Low Power Embedded Processor Small Amount of Code and Data Memory

RF

SPI SPI

Radio-stack Radio -Stack usually Usually SiP chip chiporor discrete discrete stack stack (Sometime (Sometime SoC SoCwith with with embedded embedded processor) processor)

Figure 4.2

Schematic of two-chip architecture.

74

Technology Selection

Or another RF device

UART

Either/Or

ADC

I 2C

Sensing or Actuating Device (e.g., BP, heartbeat, magnetic switch, etc.)

Low Power Embedded Processor Small Amount of Code and Data Memory

RF

SPI

Radio-Stack Radio -Stack Usually SiP chip chiporor discrete discrete stack stack (Sometime SoC with with embedded embedded processor) processor)

Figure 4.3

Schematic of single-chip architecture.

An explanation of the purpose of the prototype and how it fits into the systems architecture. The purpose section also includes high-level requirements for the device, assumptions about interdevice communications, and software assumptions. The stakeholders in the prototype design and development. These may include senior reviewers, managers, regulatory and/or manufacturers’ representatives, test engineers, systems architects, software, and firmware engineers and others. The overall requirements of the electrical functionality of the device. These requirements and constraints should be captured in as much detail as possible to help in the design. As the design progresses, this section is amended to include the design choices made, and to document the underlying reasons for these choices. A risk assessment for the device, which documents the manner in which the device deals with common wireless technology issues in a healthcare environment. These may include [14]: • • • • • •

Performance; Interference with other wireless devices (coexistence); Quality of service; Data integrity; Security; Standards and compatibility.

The risk assessment should particularly consider the manner in which the device is expected to be used, any misuse that can be foreseen, possible sources of radio interference, and the potential of the device to interfere with other devices. The use of FMEA analysis (see Chapter 3) may be appropriate.

4.4 Hardware Choices

75

The requirements for the user interface and the mechanical design requirements. Once again, as the design progresses, the section is amended to include the design choices made, and to document the underlying reasons for making them. The relevant design assumptions, design options, and suggestions to firmware engineers engaged on the project. The hardware and firmware engineers may not be colocated, or it may be the device is reused without access to the original team. As a result, documenting all firmware assumptions and the design choices made by the hardware engineers is critical. The bill of materials, assembly instructions, and prototype costs. The end user documentation and deployment notes from the design team going forward. The list of documents that reference or may be referenced for the prototype. For example, in some architectures, two separate boards are utilized to take advantage of modularity when investigating several different possible prototypes. In such a case, baseboard and daughterboards would each reference each other in this section. The signature blocks for the stakeholders and approvers. Appendices may be added that include component data sheets or supplier quotes. 4.4.6

Hardware Prototyping and Design Review

As the final hardware choices are being made the base embedded processor architecture is usually known. At this point in the process the hardware engineers may begin seeking and purchasing evaluation boards. These evaluation boards include power management, radio modules, sensors, switches, LCD, LEDs, relays, and other devices attached to an embedded processor. The boards may come with reference schematics and often with firmware examples. Leveraging the collateral in these evaluation boards and schematics gives the hardware designers an opportunity to validate their designs before manufacturing a custom board or module. By working closely with the firmware engineers and software teams, these evaluation boards may be modified to enable the development of a proof of concept before extensive investment in design has been made. Once the final hardware designs are completed and before beginning manufacturing, it is recommended to have a design review of the device by the team. The design review should include a review of the requirements, constraints, and assumptions in the design in their last form before the review. In the design review, a walkthrough of the design should also be carried out. The walk-through of the design should include the following: • • • • •

The usage model and human interaction; How the sensors gather or the actuators display the data; The decisions made by the embedded devices or data aggregators; When and how communication of the data is done; How the data is stored.

76

4.5

Technology Selection

Firmware Choices Working closely with the hardware engineer, the firmware engineer selects the embedded processor for the design. In making this choice, the firmware engineer selects the development environment, compiler, and debugger and decides whether an operating system for the device can be or should be used. Some of the smaller low-cost embedded processors do not support real-time operating systems as such, but rely on a loop program running continuously with interrupts to program the device. Some embedded IC devices are restricted to lower level assembly languages, although the most popular processors support a higher-level programming language like C. In such higher-level language compilers, a suite of validated subroutines for the embedded device are included. While designing the firmware, the engineer may need to augment these libraries with additional assembly language routines. When making these decisions, the firmware engineer should document them as part of the design process. 4.5.1

RTOS or Simple Scheduler?

A smaller application may not require a full real-time operating system (RTOS). Using a forever loop with information storage and reteival (ISR) offers a lower level of functionality, but is adequate for many sensor devices. When building a bigger device, such as a gateway, a RTOS is indispensable, however. In order to build support for TCP/IP, for USB mass storage devices or to provide parallel execution of software tasks, a RTOS is necessary. Depending on the real-time requirements of the solution, a version of Linux may also be considered. For very small devices, a proprietary scheduler may be perfectly adequate. 4.5.2

Operating System

While small embedded processors, as noted above, may not support the use of real-time operating systems, an increasing number of devices do provide systems software that offers services analogous to those available from an operating system. Table 4.4 shows a cross-section of available devices and the operating systems which they use. The open source operating system TinyOS is a clear leader in terms of popularity; this operating system is explored in the following sections. 4.5.3

TinyOS

One common embedded operating system that is gaining traction in the wireless community is TinyOS. TinyOS is an event-based operating environment designed for use with networked sensors. This programming environment supports a variety of low-power devices, with a few kilobytes of memory and wireless communication capabilities [19]. It is designed to support the concurrency-intensive operations required by networked sensors with minimal hardware requirements. TinyOS is based on the nesC programming language. nesC is an extension to C [22], designed to embody the structuring concepts and execution model of TinyOS [23] and uses the custom nesC compiler. The nesC language supports programming structured

4.5 Firmware Choices Table 4.4

77

Common Operating Systems

Sensor Name

Microcontroller

OS

BEAN

MSP430F169

YANTOS

uPart

Microchips rfPIC16F675

UPart Logger

Mulle

Renesas M16C/62

TinyTimber

AWAIRS 1

StrongARM SA1100

TinyOS

BSN

MSP430

TinyOS

BTNode

ATmega128L

TinyOS

CITNode

PIC16F877

TinyOS

COTS Dust Family

AT90LS8535

TinyOS

DOT

ATmega163

TinyOS

DSYS25

Atmega128L

TinyOS

EnOcean

Microchip PIC18F452

TinyOS

ntblEyesIFX 1/2

MSP430F149 MSP430F1611

TinyOS

Fleck

Atmega128L

TinyOS

Imote 1

ARM7 Core

TinyOS

IMote 2

Intel PXA 271

TinyOS

KMOTE

MSP430

TinyOS

MICA

ATmega103

TinyOS

MICA2Dot

ATmega128L

TinyOS

MICAz

ATmega128L

TinyOS SOS MantisOS

MICA 2

ATmega128L

TinyOS

Pluto

MSP430F149

TinyOS

René

ATmel 90LS8535

TinyOS

René 2

ATmega163

TinyOS

RISE

Chipcon CC1010 Renesas M16C/28

TinyOS

SHIMMER

MSP430F1611

TinyOS

TELOS/Tmote Sky/SkyMOTE

TI MSP430F149

TinyOS SOS MantisOS

TinyNode 584

MSP430

TinyOS

Tyndall Mote

ATmega128L

TinyOS

WiseNet

Chipcon CClOlO

TinyOS

SunSPOT

ARM7 Core StrongARM920T

Squawk

ProSpeckz

AtmelAT91 (ARM7TDMI core)

Specknet

T-Nodes

ATmega128L

SOWNet

XYZ

ML67 Series ARM/THUMB

SOS

Smart-its

ATmega103L PIC16F876 PIC16F877

Smart-Its

RFRAIN

Chipcon CC1010 (8051)

RFRAIN libraries

78

Technology Selection Table 4.4

(continued)

Sensor Name 3

Microcontroller

OS

PIC18F452

Pavenet

MEDUSA MK-2

ATmega128L AT1FR4081 ARM THUMB

PALOS μCos-II

IBadge

ATmega 103L

PALOS

U

FireFly

ATmega32L

Nano-RK

MITes

nRF24E1 (8051 CORE)

n/a n/a

PicoNode

StrongARM SA-1100

WeBee

8051 Microcontroller

n/a

Nymph

ATmega128L

MANTIS

GNOMES

MPS430F149

GNOMES OS

Sensinode

MSP430

FreeRTOS, NanoStack TinyOS

SquidBee

ATmega168

Firmata

Ember

ATmega128L

EmberNET

WINS

StrongARM SA-1100

eCOS RTOS

ScatterWeb/ESB

MSP430F149 MSP430F1612

Contiki TinyOS

Ant

MSP430F1232

Ant

μAMPS

StrongARM SA-1100

μOS

AquisGrain

ATMega128

—

Spec

AVR like RISC core

—

SpotON

Dragonball EZ

—

component based applications. The source code for both nesC and TinyOS is freely available (e.g., on SourceForge). The TinyOS system, libraries, and applications are written in nesC. The language supports the TinyOS concurrency model, which is based on tasks and hardware event handlers. TinyOS executes a program using two threads, one containing tasks and another containing hardware event handlers [24]. The nesC compiler detects data races at compile time. Tasks are scheduled by TinyOS but are run to completion and do not preempt each other. Hardware event handlers are initiated by hardware interrupts and may preempt tasks or other event handlers and also run to completion. A common problem with the use of threads in real-time operating systems is that they require a large amount of RAM. Each thread has its own private stack that has to be stored when a thread is waiting or idle. RAM is a constrained resource on sensor node platforms and therefore TinyOS only uses the two threads discussed [20]. 4.5.3.1

TinyOS Program Architecture

For experienced C or C++ developers, writing a small nesC programs is a relatively simple task, requiring implementation of one or more modules and wiring them together. A nesC application is composed of one or more components linked

4.5 Firmware Choices

79

together to form an executable (see Figure 4.4). Every nesC application is described by a top-level configuration that wires together the components inside. 4.5.3.2

Components

Components are the building blocks of nesC applications. A component provides and uses well-defined bidirectional interfaces. In some ways, nesC components are similar to C++ or Java objects [25]. For example, they encapsulate state and couple state with functionality. However, unlike C++ and Java objects, which refer to functions and variables in a global namespace, nesC components use a purely local namespace. This means that in addition to declaring the functions that it implements, a component must also declare the functions that it calls. There are two types of components in nesC, modules and configurations. Modules provide application code, implementing one or more interface. Configurations are used to assemble modules together, connecting interfaces used by modules to interfaces provided by others. Every nesC application is described by a top-level configuration that wires together the modules inside. For one module to interact with another, a set of names in one module, generally an interface, has to be mapped to a set of names in another module. In nesC, connecting two modules in this way is called wiring. Modules will implement programs and configurations compose modules into larger abstractions (see Figure 4.5). 4.5.3.3

Interfaces

An interface is bidirectional and acts as the only point of access to a component. An interface declares a set of functions called commands that the interface provider

Figure 4.4

nesC Component-based architecture.

80

Technology Selection

Figure 4.5

Wiring modules together with configuration.

must implement and another set of functions called events that the interface user must implement. For a component to call the commands in an interface, it must implement the events of that interface. A single component may use or provide multiple interfaces and multiple instances of the same interface [19]. 4.5.3.4

TinyOS Concurrency Model

As mentioned above, TinyOS executes a program using two threads, one containing tasks and another containing hardware event handlers. Tasks are functions whose execution is deferred. Once scheduled, they run to completion and do not preempt one another. Hardware event handlers are executed in response to a hardware interrupt and also run to completion, but may preempt the execution of a task or other hardware event handler. Because sensor nodes have a broad range of hardware capabilities, TinyOS has a flexible hardware/software boundary. In real-time embedded systems hardware operations are almost always split-phase rather than blocking [26]. An important characteristic of split-phase interfaces is that they are bidirectional, there is a down call to start the operation, and an up call (asynchronous event) that signifies that the operation is complete (see Figure 4.6). 4.5.3.5

Tasks

In some real-time operating systems, tasks and threads can mean the same thing (or at least the two terms are used interchangeably). However, tasks in TinyOS are not the same as threads; there are only two threads of execution and tasks make up one of these threads. Tasks are nonpreemptive. This means that only one task runs at any time, and TinyOS doesn’t interrupt one task to run another. This has the advan-

4.5 Firmware Choices

Figure 4.6

81

TinyOS split-phase operations.

tage that you don’t need to worry about tasks interfering with one another and corrupting each other’s data. However, it also means that tasks should be kept short. If a component has a very long computation to execute, it should be broken into multiple tasks. While TinyOS is only one example of systems software for sensor devices, it serves to illustrate how firmware deals with the constraints of the embedded environment—small processors, limited memory, low power, and so forth. 4.5.4

Communications Standards: ISO/IEEE 11073

An important aspect of firmware is the protocol used to communicate between components of the wireless sensor network—between devices and aggregators (in a star configuration) and between devices, other devices and aggregators (in an ad hoc configuration). Efforts to standardize the communications protocols used in the healthcare information technology environment have been ongoing since the 1980s, and currently fall under the remit of the IEEE-led ISO 11073 standards committee. Traditionally, major suppliers of healthcare information technology have promoted their own proprietary models for data communication. This has tended to lock consumers into commercial relationships, and allowed producers to develop their solutions without needing to take other industrial suppliers into account. However, increasing pressure is being placed on suppliers by healthcare purchasers (who tend to be few in number, but with large budgets), to deliver solutions that comply with the relevant standards. This can potentially increase interoperability among devices, as well as enabling easier changes of supplier and supporting competitiveness in the market. The IEEE 11073 series of standards defines the protocol data units that are sent between devices (“agents” in the standards terminology) to aggregators (“managers” in the standards terminology), in terms of the management fields and the payload which they include. Note that the standards apply to wired networks as well as WSNs. The standards ignore the details of the communications technology that the protocol data units travel across (Bluetooth, WiFi, ZigBee, USB, etc.). The philoso-

82

Technology Selection

phy of the standard is to maximize the burden on the manager, and allow the agent to be as lightweight as possible. The standards explicitly address: • • • • • • • • • • • •

•

• • •

Three healthcare domains; Disease management; Health and fitness; Independent living (aging independently); Data management; Streaming from agent to manager; Storage and later upload to manager; Occasional communication; Efficient connection and reconnection; “Best effort” communications; Reliable communications; Defined numeric values to be used in the data units for: •

Device type

•

Metric

•

Numerical values

•

Accuracy indications

•

Real-time waveforms

•

Scales, ranges, etc.

Application profiles (subsections of the standards) for different classes of device; Pulse oximeter (-10404); Blood pressure (-10407); Glucose (-10417);

While IEEE 11073 is gaining traction, uptake by major manufacturers has not been notably rapid. Given the rapid evolution of multipurpose communications protocols leveraging TCP/IP and XML, the possibility remains that IEEE 11703 may be replaced by a multipurpose protocol in the future.

4.6

Software Choices 4.6.1

Software Considerations

Because building a wireless sensor product involves many layers of software, some analysis can be useful. The following questions may be considered when assessing the software needs of a sensor platform and the available hardware: • • •

What programming languages are supported? What microprocessor, memory, and storage resources are available? Is there an operating system?

4.6 Software Choices

83

Sensor to Aggregator Communications Interface Another important element of the firmware and system configuration is the establishment of a communication interface between the wireless device and the data aggregator or other wireless devices. For example, in the system architecture below, each subject has a body sensor network made up of one or more sensor nodes that are strategically placed on the body for health monitoring. The primary functions of these sensor nodes is to unobtrusively monitor motion, gait, vital signs, and other relevant kinematic and physiological data and stream this data to a local server through wireless personal area networks. The body sensor controller (BSC) captures data from the sensors as well as monitoring and controlling the operation of the sensor network. The interface between the BSC and the body sensor network enables body sensors to be configured, commanded, and controlled through simple ASCII strings through a local transport connection. The BSC performs this configuration. The BSC could be a PC, PDA, handset, or any other suitably powerful electronic device. The transport connection may be 802.15.4, Bluetooth, or an alternative personal area network type protocol.

Remote configuration of body sensor networks

Local configuration of body sensors

BSN: commands

BSNC Body sensor network controller

• • • •

BS: commands

BSC Body sensor controller

Is the code that ships with the board proprietary or is it open source? Can you modify it freely in the development of your product? What is the software road map of the vendor? Are they planning to keep up with newer revisions of the standards?

84

Technology Selection

Some vendors have some parts of their code offered as open source. An example is Meshnetics, with their OpenMAC offering for the 802.15.4 MAC layer. 4.6.2

Programming Languages

The majority of sensor development kits use C/C++ as a development language. An interesting exception is Sun Microsystems’ SPOT offering. SPOT (Small Programmable Object Technology) uses a special JVM called Squawk. The hardware for the Sun SPOT is at the upper end of what is currently available, with a 180MHz 32-bit ARM920T core processor with 512K RAM and 4M Flash. SPOT development is done in Java and popular IDEs like NetBeans can be used to debug and deploy the application. While this represents an attractive prototyping platform, a shortcoming is that the kit comes with 802.15.4, but no ZigBee stack or anything that can handle mesh networking. 4.6.3

IDE and Compilers

Integrated development environment and compiler choices are as personal as selecting an email application or a Web browser. Some developers favor proprietary applications from established vendors, while others prefer open-source platforms like Eclipse. The fundamental issue here is that the IDE provide all the necessary functionality. Care should be taken with some open-source IDEs that come bundled with sensor software; these may not deliver as much functionality as the most popular (OS or proprietary) IDEs. 4.6.4

Transparency of Source Code

It is important to establish the transparency characteristics of all layers of software before a selection is made. In many cases, network and transportation layer code comes in the form of a library and the developer is not able to see the source code. The critical issue is how these layers act when deployed in a product where an issue needs to be resolved. The engineer must be able to resolve any such issue; having well-documented code libraries, ideally with access to the source code and with timely supplier support, will be essential. 4.6.5

Data Management

The sensor network will generate substantial amounts of data over time. The always-on nature of the network, and the fact that it is planned to deploy and maintain the network for years at a time, means that the amount of raw sensor data being generated is quite significant. This raw data will be analyzed by database and data mining software, in order to provide the required information to the clinician, and to allow medical trends and patterns to be established for the individual subjects. The choice of database and data mining/analysis software is not explored here in any detail. The tools and technologies are not specific to the sensor domain. Data mining and visualization requirements are the same across many domains, and

4.7 Field Experience #1: Radio Enclosures

85

there are many commercial and open-source products available. This topic is not covered in further detail here. 4.6.6

Conclusion

Successful design involves the translation of clinical or research requirements into a technology solution. The first key step to success is to fully understand the requirements; this is explored in some detail in Chapter 3. Having fully ascertained what must be achieved, the engineer must architect his solution, bearing in mind both the functionality of the system and the environment in which it must operate. The environment may have multiple aspects to be considered, including regulatory, user-centric, and economic perspectives. The choice of technology (hardware, firmware, and software) will be driven primarily by the requirements and by the environment in which the solution is to be deployed. The various technology elements will also influence one another. The hardware choice will be influenced by the software it supports; the software choice will be influenced by the specific requirements of the project, by the hardware platforms it runs on, and by other factors. This chapter have provided some guidelines and outlined some techniques that will be of use to the engineer in the design process. However, it is important that the engineer bear in mind that there is always more than one solution to any particular problem, and that time spent considering all reasonable options will be well spent.

4.7

Field Experience #1: Radio Enclosures This section presents a description, analysis, and lessons learned from a field work experience where a new WSN was set up for healthcare purposes. The focus of the field work was on testing of radio communications in a variety of environment. The radio range testing took place in three distinct testing venues: the cubical office, the open field, and a private home. By testing in the office environment, we were able to perform expedient development-test cycles by making rapid changes to the antenna and enclosure designs. The downside of testing in such an office environment was the considerable RF signal bounce off of windows, floors, ceilings, and walls. The construction of the office building was important because it may have reduced exterior noise from atmosphere conditions. Testing in the grass-covered field eliminated the issues associated with bounce of the RF signal from sources other than the ground. This environment was similar to the environment used by the radio manufacturers. Finally, testing in the home gave us the opportunity to test the radios in the same environment in which they would be deployed. The home environment consisted of a two-story dwelling in the northwestern United States, constructed of wood framing with T10 siding material. Testing was done only on the lower floors of the home; a diagram of the home is shown in Figure 4.7. Each radio system was tested as delivered, and tested while mounted in two of our designed containment enclosures. The enclosures—two different colors of polymer plastic material were used—contained a printed wiring board (PWB) that sup-

86

Technology Selection

Location #2

Base station

Location #3

Location #1

Front door

Figure 4.7

Diagram of the home testing environment.

plied power to the radio and to the sensor, as well as two AA batteries. Each of the radios was tested using fresh batteries at the beginning of the test. We tested four units of each type of radio to identify any variability that may have existed in manufacturing. A small test program was written in TinyOS that lighted a specific color LED to indicate the percentage of beacon packets returned to the radio, thus determining useful range. The first tests used the radios as shipped by the manufacturer, without enclosures. A second round of testing was conducted using the black enclosure and then using the white enclosure with the radios mounted within the enclosures. The results tables show a dramatic difference between the unenclosed and enclosed radio results. In order to discover what caused the difference, we analyzed the enclosures themselves. Samples of the black and the white enclosures were tested using scanning electron microscopy/energy dispersive spectroscopy (SEM/EDS) (Figures 4.8 and 4.9). One-centimeter-square samples from each of the enclosures were removed and coated with Au/Pd for the analysis.

Table 4.5

Results of the Radio Sensors Range Test Using the Green Light as a Criterion iMote

MICAZ

MICA2-433

Office

300 ft*

300 ft*

300 ft*

Home

Limited ~ 80%

Limited ~ 30% All access

Limited ~ 30%

Field

500 ft**

500 ft**

158 ft

*Limited to the size of the building. **Beyond the published range.

417 ft

MICA2-915 62 ft

4.7 Field Experience #1: Radio Enclosures

87

Table 4.6 Results of the Radio Sensors Range Test While Mounted in the Enclosures Using the Green Light as a Criterion iMote

MICAZ

MICA2-433

MICA2-915

143 ft

300 ft

149 ft

35 ft

Home, black box

Limited ~ 70%

Limited ~ 30%

All access

Limited ~ 30%

Field, black box

500 ft**

500 ft**

417 ft

40 ft

Office, white box

89 ft*

300 ft*

300 ft*

62 ft

Home, white box

Limited ~ 80%

Limited ~ 30%

All access

Limited ~ 5%

Field, white box

500 ft**

500 ft**

417 ft

40 ft

Office, black box

*Limited to the size of the building. **Beyond the published range.

Electron image 1

200 μm

60 μm

Electron image 1

(b)

(a)

Figure 4.8 (a, b) SEM micrograph of the fractured surface of the black enclosure. Increasing magnification scanning electron microscopy (SEM) views of the black housing show a relatively homogeneous structure (top). From the micrographs one can see the relatively smooth fracture surface when compared to Figure 4.9.

200 μm 500 μm

(a) Figure 4.9

Electron image 1

Electron image 1

(b)

(a, b) SEM micrograph of the fractured surface of the white enclosure.

88

Technology Selection

By comparison it is clear there is a greater cross linking in the polymer of the white enclosure compared to the black enclosure. Using these samples, an energy dispersive spectroscopy (EDS) analysis was performed, with the results shown in Figures 4.10 and 4.11. From the EDS results the differences in the elemental compounds of the two materials is titanium (Ti). Titanium occurs in the white enclosure, but not in the black, while both samples had carbon and oxygen as ingredients. Based on these results the antennas of the radios were moved to the exterior of the white enclosure. The authors suspected the titanium was acting as Faraday cage in containing the radio signals within the enclosure. Based on the results of moving the antenna to the exterior of the white enclosures, there was a sufficient added range to cover the entire home with sensors. These results show that a device’s enclosure material may have significant impact on its radio range. Elements added to achieve different colors may impact the wireless transmissions by causing the enclosure to contain the radio waves, much like a Faraday cage.

Figure 4.10

EDS results of the fractured surface of the black enclosure.

Figure 4.11

EDS results of the fractured surface of the white enclosure.

4.8 Field Experience #2: Bluetooth Testing

89

Table 4.7 Results of the Radio Sensors Range Tested While Mounted in the Enclosures with an Externally Mounted Antenna, Using the Green Light as a Criterion iMote

MICAZ

MICA2-433

MICA2-915

Office (white box)

300 ft*

300 ft*

195 ft

62 ft

Home (white box)

All access

Limited ~ 30%

All Access

Limited ~ 30%

Field (white box)

500 ft**

500 ft**

417 ft

40 ft

*Limited to the size of the building. **Beyond the published range.

4.8

Field Experience #2: Bluetooth Testing This section presents a second example of field work, which is directly relevant to the material presented in this chapter. It outlines the process used and the results gained from an experiment, which tested the Bluetooth radio stack in a home environment. 4.8.1

Introduction

Defining the requirements for any assisted living solution deployment greatly impacts the choice of wireless technology solution. Initial solutions will likely focus on the deployment of between one and six sensors into the home environment connected to a central hub, quite possibly a PC with appropriate integrated radios. While hardwiring offers the most reliable means of device connectivity; it is normally impractical to install new wiring in an existing home due to significant installation costs and aesthetic impact. Wireless networking has the advantage of addressing these short comings, and, of course, untethers the devices themselves. There are a number of candidate radio technologies thay can used to connect devices in an assisted living technology solution, including 802.15.4/ZigBee, Bluetooth, and UWB and 802.11 [9, 10]. These technologies are surveyed earlier in this chapter. While many theoretical models exist to predict the performance of these technologies in controlled environments there has significantly less work presented on how these technologies perform in real-world deployments or uncontrolled environments [11, 12]. Here we summarize findings of an in-home survey of Bluetooth sensor performance. Also presented are recommendations regarding antenna selection and sensor placement in homes. 4.8.2

Experimental Process

A Bluetooth sniffer was placed in proximity to a host PC, sampling a variety of different hardware, software, and antenna configurations, in a central location in each of seven homes of varying size, configuration, and construction. Packets were collected by the sniffer and then fed to a protocol analysis application (FTS4BT from Frontline). This provided analysis of the packets, characterizing packets received as having no error; header errors; payload/CRC errors; or retransmitted. The ratio of these four categories formed the primary assessment of the radio performance.

90

Technology Selection

Additional RF spectrums were captured to determine the background interference levels in the 2.4- to 2.5-GHz ranges using a mobile spectrum analyzer (Protek 3290). Spectrums were also captured in proximity to devices that emitted in the same frequency band as Bluetooth, particularly microwave ovens and 802.11 access points. The general configuration used is shown in Figure 4.12. The experiments were fairly straightforward: Connectivity was established, and the sensor was then moved away from the PC and sniffer towards an extremity of the house. The distance at which communications failed was noted. This process was repeated in a number of directions, and on each floor if the house had two stories. The maximum point of communications was noted on a scaled plan of each home as shown in Figure 4.13. Data from a minimum of four locations per floor, per hardware set, was collected. The composite performance of the 72 Bluetooth channels is shown as a pie chart. The charts indicate the following information: • • • • •

The total number of packets collected; The number of packets with no errors; The number of packets that have header errors; The number of payload errors; The number of retransmits.

Based on the results of moving the antenna to the exterior of the white enclosures, there was a sufficient added range to cover the entire home with sensors.

Bluetooth sniffer Frame analyser Sensor unit

2345 4546 7834 8753 3573 4546 9932 4549 2394 2324

Sensor data

Bluetooth receivers internal and external antenna Hyper terminal

Figure 4.12

Survey configuration.

4.8 Field Experience #2: Bluetooth Testing

Figure 4.13

91

Ground-floor plan of surveyed home.

These results show that a device’s enclosure material may have significant impact on its radio range. Elements added to achieve different colors may impact the wireless transmissions by causing the enclosure to contain the radio waves, much like a Faraday cage. Background RF spectrums in the 2.4- to 2.5-GHz range were also collected. A typical spectrum obtained is presented in Figure 4.14. Spectrums were also collected with microwave ovens switched on to determine their impact on data transmissions.

Figure 4.14

Background spectrum from kitchen area.

92

Technology Selection

4.8.3

Results

The results indicate that the effective range of a Bluetooth-enabled sensor to communicate reliably in a residential environment is limited. The results clearly indicate the challenges of positioning sensor devices in home environments. The position of the node was found to have a significant effect on connectivity. Random selection of the sensor position and host positions can significantly impact range and reliability. During the experiment, positioning of the sensor focused on placing it in the extremities of the houses where it was possible to create the longest linear distance between the sensor and host. As outlined in Table 4.8, above the average range was approximately 4.5m; the best performing dongle had an average range of 7.41m while the worst had a range of 2.76m. 4.8.4

Conclusions 2

The average house size in Ireland is 88.3 m [13]. If this area was distributed over a single story, then none of the devices tested could reliably connect to sensors placed in the extremities of the house while the host was placed in an opposite extremity. This highlights the fact that an external antenna is essential on both the sensor and host if the desired ranges of connectivity are to be achieved. One major point of consideration is that antenna must be designed with the appropriate gain and radiation pattern for a particular application, in this case connection of sensors in an uncontrolled environment. While it is clear that a class one device should provide the sought-after range of connectivity (100m), this is unsuitable for our application. The results indicate the generalized designs adopted by many Bluetooth dongles are insufficient to provide the required levels of reliability and range for assisted-living technology applications; fortunately, a number of standard 2.4-GHz antennas are available from various suppliers, offering different options for placement, pattern, gain, and physical mounting. The results also indicate the type of building construction has a significant impact on link quality. The smallest house studied house (66 m2) could not be successfully covered by a single point-to-point Bluetooth connection due to the solid construction of the internal walls. Houses that have studded partition walls facilitated much longer ranges. Houses with solid first floors further limit the range of reliable connectivity. The background RF spectrum data suggests that within urban environments, measurable amounts of RF interference (–20 to –30 dB) exist from sources such as Table 4.8

Comparison of Five Bluetooth Dongles Tested

Class

BT D1

BT D2

BT D3

BT D4

BT D5

2

2

1

1

1

Average (m)

2.76

4.53

4.34

4.82

7.41

Variance

1.94

1.51

2.98

2.46

4.73

Standard deviation

1.39

1.23

1.73

1.57

2.17

BT D = Bluetooth Dongle [1–5], BT D1–D4 = internal antenna, BT D5 = external antenna.

4.8 Field Experience #2: Bluetooth Testing

93

Bluetooth-enabled phones, PDAs, and wireless LAN (IEEE 802.11) access points. In contrast, the lack of any background interference in rural locations was striking. No measurable impact was observed from 802.11 sources even when the sensor was colocated with the access point. This indicated the effectiveness of the Bluetooth’s adaptive frequency hopping scheme.

References [1] [2] [3] [4] [5] [6] [7] [8] [9]

[10]

[11] [12]

[13]

[14] [15]

[16]

[17] [18]

[19]

Bharathidasan, A., and V. A. S. Ponduru, Sensor Networks: An Overview, Technical report, Department of Computer Science, University of California, Davis, 2001. Akyildiz, I. F., W. Su, and Y. Sankarasubramaniam, et al., “A Survey on Sensor Networks,” IEEE Communications Magazine, August 2002. IEEE 802.15.4 Wireless Networks Users Guide, www.jennic.com/support. ZigBee Stack Advanced User Guide, Jennic, JN-UG-3045, Revision 1.2, March 6, 2008, www.jennic.com. Gallev, M., “Catching the Z-Wave,” Embedded Systems Design, Oct. 2, 2006, www.embedded.com. Freescale Semiconductor, IEEE 802.15.4/ZigBee Software Selector Guide, September 2007. Z-Wave Alliance Day Technical Seminar, June 14, 2005. Hristozov, A., “Selecting a Wireless Sensor Development Platform,” www.embedded.com. Ramamurthy, H., B. S. Prabhu, and R. Gadh, “Application of Generic Reconfigurable Wireless Interface for Industrial Automation Scenarios,” U.S. Patent Disclosure, UCLA Case No. 2006-002-1 (pending). Opperman, L., A. Stoica, and Z. Rabbachin, et al., “UWB Wireless Sensor Networks: UWEN—A Practical Example,” IEEE Radio Communications, December 2004, pp. 27–32. Dishongh, T., K. Rhodes, and B. Needham, “Short Range Radio-Frequency Issues for Sensors Installed in a Home Environment,” SMTA PAN PAC, Kauai, HI, Jan. 22–24, 2005. Dishongh, T., “Room to Room Location Tracking of Elders,” 2nd International Workshop on Wearable and Implantable Body Sensor Networks, Imperial College, London, Apr. 12, 2005, pp. 18–20. Evans, A. W., and O. M. Hartwich, Unaffordable Housing Fables and Myths, Policy Exchange, June 2005, http://www.policyexchange.org.uk/Publications.aspx?id=160, Nov. 2007. Draft Guidance for Industry and FDA Staff: Radio-Frequency Wireless Technology in Medical Devices, released Jan. 3, 2007, http://www.fda.gov/cdrh/osel/guidance/1618.pdf. Krishnamoorthy, S., et al., “Characterization of the 2.4 GHz ISM Band Electromagnetic Interference in a Hospital Environment,” Proceedings of the 25th Annual International Conference of the IEEE, Vol. 4, 2003, pp. 3245–3248. Gieras, I. A., “The Proliferation of Patient-Worn Wireless Telemetry Technologies within the US Healthcare Environment,” Information Technology Applications in Biomedicine, 4th International IEEE EMBS Special Topic Conference, April 24–26, 2003, pp. 295–298. Oyri, K., et al., “Wireless Continuous Arterial Blood Pressure Monitoring During Surgery: A Pilot Study,” Anesthesia & Analgesia, Vol. 102, 2006, pp. 478–483. Høgetveit, J. O., et al., “Introducing Multiple Wireless Connections to the Operating Room, Interference or Not?,” The 3rd European Medical and Biological Engineering Conference, EMBEC ‘05, Prague, Czech Republic, November 20–25, 2005. Istepanian, R. S. H., et al., “Medical Wireless LAN Systems (Med-LAN). State of the Art, Challenges, and Future Directions”, eHealth conference, City University, April 2001.

94

Technology Selection [20] Lin, J. C., “Health Aspects of Wireless Communication: A Real and Present Wireless Danger,” ACM SIGMOBILE Mobile Computing and Communications Review, Vol. 4, No. 1, January 2000, pp. 17–18. [21] Davis D., B. Segal, and T. Pavlasek, “Can Minimum Separation Criteria Ensure Electromagnetic Compatibility in Hospitals? An Experimental Study,” Biomed. Instrum. Technol, Vol. 33, 1999, pp. 411–416. [22] Golmie, N., D. Cypher, and O. Rebala, “Performance Analysis of Low Rate Wireless Technologies for Medical Applications,” Computer Communications, Vol. 28, No. 1010, 2005, pp. 1266–1275.

Useful Links • •

• • • • • • • • • • • • • • • •

http://www.rabbit.com/products/ZigBee_App_Kit/index.shtml http://www.freescale.com/webapp/sps/site/overview.jsp?nodeId= 01J4Fs25659873 http://www.xbow.com/Products/productdetails.aspx?sid=160 http://www.willow.co.uk/ http://www.ccsinfo.com/product_info.php http://sunspotworld.com/ http://www.jennic.com/products/index.php?productID=0000000011 http://www.meshnetics.com/dev-tools/zdk/ http://www.ember.com/products_zigbee_development_tools_kits.html http://www2.okisemi.com/site/productscatalog/Zigbee/ZigbeeZDK.html http://www.zen-sys.com/index.php?page=9 http://focus.ti.com/docs/toolsw/folders/print/z-stack.html http://www.moteiv.com http://www.silabs.com/tgwWebApp/public/web_content/products/ http://focus.ti.com/docs/prod/folders http://www.freescale.com/zigbee http://www.z-wavealliance.com/content/uploads/ http://www.embedded.com

CHAPTER 5

Data Collection and Decision Making Healthcare applications that leverage wireless sensor networks (WSNs) analyze the data gathered by sensors to infer and make decisions about the state of a patient’s health and wellbeing. These decision models or algorithms use sequences of sensor firings called chains to represent quite complex physical systems. Understanding the decision algorithms, inferring, extrapolating, or interpolation of the acquired data is called predictive analytics or machine learning. Generally, the field of predictive analytics entails the use of a multitude of techniques from statistics, artificial intelligence, and data mining based on previous collected or learned knowledge to make decisions about the present state or future. The field of predictive analytics can be divided into three general categories of model types: predictive models, which make near-term projections based on previous data; descriptive models, which classify data based on commonality of characteristics in the data; and decision models, which are used to interpret data and take actions based on the interpretation, according to a predefined set of rules [1–10]. Healthcare applications often leverage decision models to build inference engines—software that can be used to infer a person’s state based on sensor data. In this chapter, an overview of an inference engine and its architecture are given, and three types of inference engines are discussed: static rules-based models, statistical models, and Markov and Bayesian models.

5.1

Introduction to Inference Modeling In WSN healthcare applications, inference models are used to automatically determine what activities people are performing by analyzing sensor data. For instance, independent living applications use inference modeling to monitor patients in their homes by analyzing data from sensors embedded in the home. Such WSN applications rely on a variety of types of sensor data, including: • •

•

•

Broad location (e.g., room-wide infrared sensors); Object-based (e.g., small sensors placed on an object and the person who uses it could provide information that that the object is being moved or used); Power usage (e.g., wall warts on outlets or built-in wired sensors that determine if lights or appliances are being used; Water usage (e.g., flow meters or acoustic sensors on pipes that indicate when water is utilized);

95

96

Data Collection and Decision Making

• • • •

Gas usage; Temperature; Audio/image/video data; Equipment-specific (e.g., phone or computer usage records).

Inference modeling often leverages software called an inference engine, a set of rules or conditions that are hard-coded. As noted earlier, inference engines can be used in healthcare applications to infer a person’s state based on sensor data. An inference engine typically includes the following components: an interpreter, a scheduler, and a consistency enforcer. The interpreter is charged with making decisions about incoming data by applying corresponding base rules. For instance, the interpreter might analyze data from sensors placed in the home of an elderly woman and decide (infer) that she has not taken her medication. The interpreter then sends this decision to the scheduler, which determines when to take action on the decision. For instance, the scheduler may determine that it is not yet time for the woman to take her medication, so it does not send her a prompt to do so. Or the scheduler may determine that the woman is not home and thus wait until she returns before sending a prompt. Finally, the consistency enforcer maintains the database from which the analysis is executed and then updates any changes from the incoming data and responses. Continuing our medication example, if the woman takes her medication in response to a prompt, the database would be updated by the consistency enforcer to prevent the woman being prompted again until it’s time for her to take another pill. 5.1.1

Categories of Inference Engines

Many books and papers are filled with discussions of various types of interference engines. For purposes of this text, the authors have subdivided inference engines into three categories: • • •

Static rules-based models; Statistical probability models; Bayesian and Markov models.

Healthcare applications use all three models. Static rules-based models are often used for mission-critical applications, such as pacemakers, which generate electrical charges to the heart based on predefined rules, and for other applications involving gathering of simple measurements. Statistical probability models are used in applications, such as the one described earlier, which involve monitoring a person and inferring the person’s behavior based on an analysis of sensor data. Bayesian and Markov models are used mainly in research, but they are also applied in speech-to-text applications and are starting to find use in other healthcare applications, such as analyzing heartbeat information to understand the daily biorhythms of a person’s heart. Simple rules-based models can be run on basic computing platforms, including sensors, while the more complex models require more sophisticated platforms. In

5.2 Static Rules-Based Models

97

particular, Bayesian and Markov models have significant requirements for both computational time and system memory. 5.1.2

Limitations of Predictive Analytics

At the core of predictive analytics is the assumption that previously captured data about a state, when combined with new information, can be used to make deterministic projections about the near future of the state. This assumption implies that human beings behave in a deterministic manner, so that any deviation from a person’s daily activities can be considered a deviation from the person’s normal daily activities. In reality, humans do not behave in such a deterministic fashion, and decision models must be able to infer whether incoming sensor data is an accurate reflection of the person’s actual state, so that the correct action (e.g., prompting the person to eat) may be taken. Consider the example of a home that is equipped with sensors for the purpose of monitoring an elderly parent. Sensor data might show that no one has entered the kitchen for the last 48 hours—a deviation in the elder’s normal routine—but that people have been moving around other parts of the house. The monitoring system might wrongly alert a caregiver that the elderly parent has not eaten, when in fact it could be that the person has had visitors for the last 48 hours and the elder has dined in restaurants during their stay. This example suggests the limitations of predictive analytics for healthcare applications. More generally, in using computational methods, especially in the field of healthcare, we should be aware of three applicable laws of computational mechanics and machine learning: •

•

•

5.2

The computer is always wrong (all solutions are numerical approximations of the truth); There is no free lunch in computing (solution error decreases as the number of inputs increases. In the case of a monitoring applications, the greater the number of sensors gathering data, the greater the likelihood of correctly inferring the person’s behavior); The answer is only as good as the question (appropriate definition of the boundary conditions and clarity of inputs decrease solution error).

Static Rules-Based Models The general architecture of a static rules-based inference engine involves two principal components: a series of static rules and a database to which the rules are applied. The static rules have two parts, an if-clause (the condition), and a then-clause (the action to take, based on the condition). The rules occur in sequences—if then ; if the conditions are true, the actions are executed. Conditions are expressions that contain attributes and a logical connective. Attributes are variables of the rule or condition and may be numerical or strings. (A string type variable can possess a value from a set of strings, for example: {true, false} or {red, yellow, green}.) A logical connective is used to tie conditions

98

Data Collection and Decision Making

together—like and, not, not equal to, and so forth. An action list (which is stored in the database) consists of one or more actions, including calling other programs, terminating processes, sending prompts, transferring information, and changing attributes. Following is a simple example of a rule: Read (temperature, complexion) if (temperature > 100 and complexion = pale ) then ( print(“Patient has the flu.”), and call Specialist) return;

When the inference engine examines rules, actions are executed if the information supplied from the database satisfies the conditions in the rules. For instance, an application embedded in a bathroom scale might be programmed to execute an action (alert a physician) if a person’s weight increases by more than 10 pounds in a short, predetermined period of time (the condition), as dramatic shifts in weight over a brief time period are leading indicators of a coronary. Two static rules-based methods are forward and backward chaining. The forward chaining method is a top-down, reactive method that makes no predictions about the future. Under this method, actions are taken as soon as data is received rather than delayed until more data is accumulated. Specifically, in forward chaining, the scheduler takes the data when it becomes available from the interpreter (e.g., data showing that a person’s weight has increased by more than 10 pounds in the last four days) and attempts to draw conclusions from satisfied conditions in rules (the person is in danger of a coronary), which leads to actions being executed immediately (the physician is notified). Backward chaining takes the opposite approach. It is a bottom-up method that starts with actions and queries of the database, which may satisfy the conditions contained in the rules. Under the backward chaining method, data is accumulated in the database over time, and the rules are mined after some period of time. Continuing the example above, the data about the person’s weight gain might be run through the rules engine several hours after the data is received. In developing a strategy for implementing a static rules-based model, two points require consideration. First, a conflict resolution strategy may need to be developed to decide the order in which rules are operated. The order of rule operation may be hard-coded in the action, as in the example above, or it may be passed back to the scheduler to consider when to run the rules through the interpreter. Another point of consideration is the issue of minimizing computational time. One method of minimizing computational time is to evaluate conditions at the time when they may change, rather than waiting for data to accumulate. It is always computationally more efficient to run the data as soon as it’s received (i.e., forward chaining) rather than waiting for data to accumulate in the database, as the latter approach (backward chaining) complicates the scheduler. For instance, in our earlier example, using forward chaining, the weight data coming from the bathroom scale is immediately run through the interpreter, which decides that the person has gained more than 10 pounds in a short period of time. The person’s physician is alerted immediately. Under a backward chaining approach, the accumulated data

5.2 Static Rules-Based Models

99

might show that the person gained 10 pounds but subsequently lost the weight. The scheduler must then determine whether or not to prompt the physician, as the weight data is conflicting. Another way to minimize computational time is to stop the computation if one attribute is false. For instance, in our earlier example of determining whether or not someone has the flu, if the attribute “temperature” not greater than 100 degrees, there is no need to check the person’s complexion. Finally, computational time can be minimized by checking rules only at a point when they can be acted upon, not before. For instance, in the example of the woman being monitored as she wanders through the house at night, the scheduler must decide when to send a prompt to the woman, asking if she is having trouble sleeping. In this case, the scheduler might decide to wait and send the prompt in the morning (the only thing worse than insomnia is continually being prompted by a message asking if you are having trouble sleeping). 5.2.1

Example of a Static Rules-Based Application

Static rules-based models are often used in sensor-based healthcare applications. We have suggested two simple rules-based applications for making decisions about weight gain and screening people for the flu. For a more detailed example of how rules-based models work, consider a system that collects information regarding activities of daily living (ADLs), such as whether or not an elderly person gets up on time or goes to the bathroom as well as whether he or she is taking medicine, eating, and doing activities around the house. The system consists of three major components: wireless sensors, an aggregator, and an actuator. The system employs a static rules-based model that sends alerts to the caregiver when the system detects movements that divert from the person’s normal pattern of activity. For instance, alerts might be sent via a Web site, e-mail, and/or phone call for the following deviations in activity/occurrences: •

•

•

The elder leaves bed late, after 10 a.m., based on motion sensor triggering in the bedroom while no other motion sensors being activated in the rest of the house. The rule that triggers the alert is based on the assumption that if the person is in the bedroom after 10 a.m., he or she may not be feeling well. The elder has more than three bathroom visits, based on motion sensors triggered during the night. Based on a simple rule, the numerous nightly restroom visits may indicate the elder is having medical issues. The elder is in the bathroom for an extended period of time, longer than an hour. The rule that triggers the alert is based on the idea that the person spending an excessive amount of time in the bathroom might have fallen.

These simple rules, based on data from simple wireless sensors, prompt humans to intervene. Systems such as these have been tested and are used effectively in nursing homes and assisted living facilities throughout the world to help nursing staff monitor patient activity.

100

5.3

Data Collection and Decision Making

Statistical Probability Models Since rules are often rigid, with no “wiggle room” (e.g., temperature either is > 100 degrees or not), rules-based models are not the best choice for all applications. Another approach to inferencing is the use of a statistical measures of confidence to suggest when a rule should be triggered. In using statistical methods, a model of a person’s routine behavior is built based on previously collected data. Subsequent data is interpreted and assigned a level of confidence based on the behavioral model. For example, if it is known that a patient has a history of cognitive impairment, it might be inferred with a 0.85 confidence level that when activity is sensed within the patient’s home after midnight, the patient is wandering around the home, based on previously collected sensor data. If the patient is known to have cognitive impairment and a history of wandering at night, the confidence level may be increased to 0.90. Confidence levels are analogous to probabilities but are more a simulation of human reasoning than a strict mathematical calculation of probability. Typically a sample set of data is used to create the statistical confidence levels. Each confidence level is derived from a different grouping of data, creating a model or class for each. For example, consider a sensor-based application that records a patient’s heart rate once every thirty minutes, 24 hours a day. By combining and analyzing heart rate information recorded at night and data from passive infrared motion detectors in the patient’s environment, it is possible to establish a model or classification of “patient wandering.” Specifically, if the patient’s heartbeat is higher than normal, and motion is sensed after midnight near the same time when the spike in heart rate occurs, one may infer with some confidence that the patient was wandering. Once classes are established and confidence levels assigned to the models or classes, new incoming data is judged against the models and labeled as either normal or a deviation from normal. To continue the wandering example, once a computer has established a model that the subject has a history of wandering between the hours of 1 a.m. and 3 a.m., if motion and body-worn sensors transmit information to the computer that motion has occurred and that the person’s heart rate is elevated above a resting level, the inference engine will compute the likelihood of the “wandering” model and compare the data against other behavioral models stored in the computer. The interpreter will choose the model that best matches the sensor data (i.e., the one with the highest level of confidence that the model accurately reflects reality) and transmit this decision to the scheduler, which may send an alert to a remote caregiver that the person is active at night and could be in danger.

5.4

Bayesian and Markov Models Bayesian and Markov models are another form of interpreters of data for the inference engine. Both are analogous to backward chaining methods discussed earlier. The September 2000 issue of The Economist is often cited for providing the most eloquent description of Bayesian models: “The essence of the Bayesian approach is to provide a mathematical rule explaining how you should change your existing

5.4 Bayesian and Markov Models

101

beliefs in the light of new evidence. In other words, it allows scientists to combine new data with their existing knowledge or expertise.” Bayesian and Markov models are conditional probabilities models, which are special cases of statistical models. Conditional probabilities are used to understand how the probability of an event A changes after it has been learned that some other event B has occurred. For instance, if a sample space S exists, and the events A and B exist within that space, and the probability of event A overlaps (depends on) event B occurring, this can be written as the probability of A given B, denoted mathematically as Pr(A | B). Bayesian and Markov models are based on Bayes’ theorem, which is a simple rule for computing the conditional probability of events A1,…, Ak given B from the conditional probability of B given each event Ai and the unconditional probability of each Ai. The proper mathematical way of expressing Bayes’ theorem is: Let events A1,…, Ak form a partition of the space S such that Pr(Aj) > 0 for all j and let B be any event such that Pr(B) > 0. Then for i = 1,..,k:

Pr( A i | B) =

Pr( A i ) Pr( B| A i ) k

Pr( A k ) Pr( B| A k )

Suppose we know that data coming from a sensor is valid 95% of the time. Further, we know that a certain event occurs rarely, just 1% of the time. Expressed mathematically, the probability that the sensor accurately infers events is Pr(Sensed Valid | True) = 0.95, the probability of inaccurate inference is Pr(Sensed Valid | False) = 0.05, and the probability of the rare event occurring is Pr(Detection)=0.01, likewise Pr(Not_Detection)=0.99. Placing this data into Bayes’ theorem, the probability of the rare event being inferred accurately is: Pr(Detect | True) =

Pr(Detected )Pr( Sensed | True) [Pr(Detected )Pr( sensed / True) + Pr( Not _ Detected )Pr( sensed / False)]

Pr(Detect | True) = 016 .

In other words, the probability of the event being true based on the sensor data is 16%. In the example above, we only considered a single sensed event for a discrete sample on a simple sensor for which we know the accuracy rate. In reality, knowing all the variables and calculating them for all possible events we can detect is not feasible. Because of this, graphical representation of Bayes’ theorem can be helpful. Elements in the graphic represent joint probability distributions as a product of connected terms of probabilities. Graphical representations of conditional probability models are call probabilistic graphical models. The graphs have nodes (often drawn as ellipses) representing random variables, and lines or arcs representing the conditional independence assumed between the variables. Two forms of probabilistic graphical models are undirected models, called Markov random field models and directed models, called Bayesian networks. In Markov random field models, two conditional independent variables, A and B, are

102

Data Collection and Decision Making

conditionally dependent on a third set of variables C, where all paths between A and B are separated by the variable set C (Figure 5.1). Bayesian networks contain independent variables that can be undirected and have arcs that link various independent variables. Once again, if we consider two sets of conditional independent variables A and B and a conditional set of variables C, Bayesian networks allow the connection to be made not only from A to C, but also A to B (Figure 5.2). To illustrate the use of Bayesian networks, consider a sensor-based application to remotely infer the state of a patient using a wireless ECG monitor. Assume that no signal has been received for a certain period of time. For purposes of our example, assume that in fact the patient is fine and there is an issue with the WSN. The ECG monitoring application is graphically illustrated in Figure 5.3. For each node in the graph, a conditional probability distribution is specified in a table listing the probability that the child node takes on different values for each combination of values of its parents. In this example, each of the variables will be binary (either true or false). The application database shows that the ECG has no signal (ECG No Signal=True), and this may be due to two possible causes: either the battery in the wireless ECG sensor is dead (Battery_Dead=True) or the transceiver (No_RF=True) did not send the data captured. The strength of the relationship for each possibility of ECG No Signal is shown in the table next to the node and likewise for each node. As we scan Figure 5.3 vertically, we can see that the probability tables grow in size, reflecting the increasing number of variables handed down by “generations” of parents.

A

B

C Figure 5.1

Markov random field model.

A

B

C Figure 5.2

Bayesian network.

5.4 Bayesian and Markov Models

103 P|No_data=True|

P|No_data=False|

0.5

0.5

ECG No Data 43

P(BD=1abc)

P(BD=1a,c)

1

0.3

0.3

1

0.9

0.1

43 BD

P(43=1abc)

Battery_Dead

P(43=1a,c)

1 1

1.0

0.0

1 1

0.1

0.9

1 1

0.1

0.9

1 1

0.01

0.99

Figure 5.3

P(40_R,1=1a,c)

43

P(40_R,1=1abc)

1

0.21

0.2

1

0.2

0.21

No_RF

ECG No Signal

Bayesian network illustrating ECG monitoring application.

Converting the graph shown in Figure 5.3 into the chain rule of probability, the joint probabilities of all the nodes in the graph can be found: Pr( ND, BD, No _ RF , No _ Sig ) = K Pr( ND)* Pr( BD| ND)* Pr( No _ RF | ND, BD)* Pr( No _ Sig| ND, BD, No _ RF )

By studying Figure 5.3, we can see that there is a conditional independence relationship that allows the equation above to be simplified, since the node, ECG No Signal is the parent to the independent nodes Battery_Dead and No_RF. Additionally, the node No_Data is independent of No_Signal because its parents are the nodes Battery_Dead and No_RF. Using the conditional independence simplification: Pr( ND, BD, No _ RF , No _ Sig ) = K Pr( ND)* Pr( BD| ND)* Pr( No _ RF | ND)* Pr( No _ Sig| BD, No _ RF )

Using the graphical structure, we can now use a Bayesian network to create a probabilistic inference. In the graph and equations above we have found that there are two potential causes for No_Signal from the wireless ECG monitor: either the battery is dead or the radio is not working. Given our example, which one is most probable? Using Bayes’ theorem, the computation of the backward chaining possibility can be calculated as follows: Pr( BD = True, No _ Sig = True) Pr( No _ Sig = True) ND , NoRF Pr( No _ Data, BD = True, NoRF , No _ Sig = True)

Pr( BD = True| No _ Sig = True) = =

Pr( No _ Sig = True)

104

Data Collection and Decision Making

and Pr( No _ RF = True, No _ Sig = True) Pr( No _ Sig = True) ND , BD Pr( No _ Data, BD, NoRF = True, No _ Sig = True)

Pr( No _ RF = True| No _ Sig = True) = =

Pr( No _ Sig = True)

Using the data from the table in Figure 5.3, we find that Pr( BD = True| No _ Sig = True) = 0.43 Pr( No _ RF = True| No _ Sig = True) = 070 .

Hence we can infer that the lack of data from our wireless ECG is likely caused by a failure of the radio transmission rather than a medical problem. 5.4.1

Field Experiences ADL Applications

In conducting their trials for ADL detection, Honeywell’s Karen Zita Haigh stated, “Experience in other domains (avionics, refineries, surgical theaters) shows that such innovations will merely produce a collection of distributed devices with localized intelligence that are not integrated, and which may actually conflict with each other in their installation and operation. Our experience shows that to consistently exhibit intelligent behavior, these networked devices will need a coordinated, situation-aware, controlling intelligence. We intended to build three main components: situation assessment and task tracking, response generation, and machine learning. In short, our experiments in the engineer homes validated our hypothesis that this domain is very complex and lends itself very well to advanced reasoning techniques.” Honeywell’s team eventually stopped using their inference software, stating “Intent recognition component was removed from the I.L.S.A. field study for two reasons. First, as experimental code, there were scalability and memory management issues that were not fully addressed; these have since been corrected under other funding. Second, in an effort to reduce the deployment cost for the elders in the field study, I.L.S.A. chose to focus on a reduced set of low-cost sensors. To fully realize the potential of the task tracking system, more extensive and higher level sensor information is required.” Thus, a main learning of the Honeywell study was the second law of computational modeling stated above holds true. A direct reinforcement of this statement comes from the Honeywell report, “Given a rich sensor suite, machine learning techniques can learn complex models of the environment, the elder, other people, and even the effectiveness of its own devices. These models can then be used by the system to improve its assessments and responsiveness. Machine learning techniques will allow a fielded system to: 1. 2.

Tune itself to the operating environment, greatly reducing the amount of tuning and knowledge acquisition required at setup; Respond to changes in the users and the domain, directly reducing maintenance costs;

5.4 Bayesian and Markov Models

3.

105

Capture the user’s preferences, enhancing system usability.

Two main barriers remain: evaluation and automatic incorporation of learned models into the system. Gathering ground-truth for I.L.S.A. was not possible: users were not willing to note every activity, nor be constantly videotaped. Our evaluations were based on eyeballing results for plausibility and then observing whether changed system behavior was more or less acceptable to the elders and their caregivers. While short-term ground truth can be gathered, researchers will need to develop good techniques for long-term evaluation. Currently, the elder-care industry will not accept a system that does not have a human-in-the loop; many other industries have regulations that explicitly prohibit automatic modifications. Our approach of presenting the results to a human before incorporating them into the system was well accepted, but is unlikely to scale to a larger community of users in its current form.” Again the Honeywell researchers found, “To adapt to changes in the client or in the environment (inevitable in this domain), we must reprogram the system. Reprogramming adds to the cost of the system and presents an inconvenience to the client.” Complexity and accuracy of the machine learning component of an ADL detection system suggests that it may need periodic adjustment and changes as well. In fact, according to Mamykina, Mynatt, and Kaufman “Due to the changing nature of medical research and health care service delivery, the expert systems need to be periodically modified or extended. In the last year there have been monthly changes in the systems to accommodate medical practice changes, user feedback, and the introduction of new surgical procedures. The expert systems have eased these maintenance tasks due to the uniformity of the expert systems architecture and the method of systems deployment. Isolating independent sets of expert rules into separate knowledge bases makes it easier to modify, test, and distribute software changes. The use of dynamically loaded, interpreted knowledge bases enables the expert systems software changes to be delivered independently of the release schedule of the software in which the expert systems are embedded.”

References [1] [2]

[3] [4] [5] [6] [7] [8] [9]

Devroye, L., L. Györfi, and G. Lugosi, A Probabilistic Theory of Pattern Recognition, New York: Springer-Verlag, 1996. Davies, J. R., S. V. Coggeshall, and R. D. Jones, and Daniel Schutzer, et al., “Intelligent Security Systems,” Artificial Intelligence in the Capital Markets, R. S.Freedman, R. A. Flein, and J. Lederman, (eds.), Chicago: Irwin, 1995. Agresti, A., Categorical Data Analysis, Hoboken: John Wiley and Sons, 2002. Enders, W., Applied Time Series Econometrics, Hoboken: John Wiley and Sons, 2004. Mitchell, T., Machine Learning, New York: McGraw-Hill, 1997. Tukey, J., Exploratory Data Analysis, New York: Addison-Wesley, 1977. Giarratano, J. C., and G. Riley, Expert Systems, Principles and Programming, 2005. Jackson, P., Introduction to Expert Systems, Addison-Wesley, 1998. Xiang, Y., F. V. Jensen, and X. Chen, “Inference in Multiply Sectioned Bayesian Networks: Methods and Performance Comparison,” IEEE Trans. on System Man and Cybernetics—Part B, Vol. 36, No. 3, June 2006.

106

Data Collection and Decision Making [10] Null, L., and J. Lobur, The Essentials of Computer Organization and Architecture, Chapter 9, Narosa, 2006. [11] Ascia, G., and V. Catania, “A High Performance Processor for Applications Based on Fuzzy Logic,” 1999 IEEE International Fuzzy Systems Conference Proceedings, August 22–25, 1999, Seoul, Korea.

CHAPTER 6

Deploying in the Field 6.1

Introduction The deployment of the wireless sensor network into the home of the subject is the final step in the process described in this book. The requirements capture, design, usage modeling, technology selection, and system architecture work all leads up to the installation of a WSN in the home of an older person and the collection of data from the network. The deployment phase involves the engineer having a high degree of contact with the subject; as a result, the relationship between the engineer and the elder is a recurring theme in this chapter. The deployment of the WSN can be broken down into the following stages: 1. 2.

3. 4. 5. 6.

Planning, where the detailed plan for this particular install of a single WSN into a single home is assembled and reviewed; Testing of all the hardware and software to be installed, and the other technology elements which are used to monitor and maintain the installation; Preinstall, where the engineer ensures that all is ready for the user facing installation process; Installation and verification of the WSN in the subject’s home; Maintenance of the WSN over time; Teardown (if appropriate) of the WSN at the end of the project.

Each stage is made up of a number of steps. Issues to be addressed during each stage are considered. The material in this chapter is informed by several real-world projects in which the authors were actively involved; examples and illustrations from these projects are included where useful.

6.2

Planning Prior to the installation of the WSN in the home of the subject, a significant amount of requirements capture, architecture, hardware and software selection, design and implementation will have been completed, as described in the earlier chapters of this book. The focus of the planning stage is to prepare for the installation of a single example of the network into a single home. The plan needs to take into account not only the overall system architecture and components, but also the specifics of the

107

108

Deploying in the Field

environment into which the installation will take place, and the subject who is being served by the WSN. The plan should include: 1.

A complete list of all the technology being deployed, including some or all of the following: •

Environmental sensor/actuator devices;

•

Wearable devices;

•

Portable devices;

•

Aggregators;

•

Servers (if any);

•

Network interface (if any).

2.

3. 4.

5. 6.

The planning process should include the engineers and architects who have designed the system, so that any underlying reasons for technology choices can be explored, if necessary. In addition, the installation team should have a strong grasp of the workings of the technology, so that debugging and problems solving (and problem prevention) can be carried out rapidly when required. A specification of the data to be collected, where and how the data is to be communicated, how it is to be processed, the nature of any actuation or feedback to users, and how data is to be stored and backed up. A description of any other system elements which will be active during the project, such as maintenance/monitoring software. A floor plan of the home into which the WSN is being installed. Consider the impact of any “special cases” locations, such as the garden, the bathroom, or the bedroom. How do special environments impact on technology choice? (See Figure 6.1.) A timescale for the installation. Contact details for the subject and for the persons who will liaise with the subject during and after the project.

The plan should provide the engineer with all the information needed to implement the installation.

6.3

Testing It is crucial that all technology is fully tested before going on-site to carry out the install. This testing should include device-level tests as well as system-wide tests, and should take place: 1. 2. 3. 4.

On the bench; In the lab; In a friendly environment, such as the home of a team member; In a suitable built environment (similar in architecture and construction to the install location);

6.3 Testing

109 12 '-2 "

10 '- 4 "

TV

TV Base Station

U

W

B 1 1 Activity D Beacon W

U

22'-8"

15'-3"

5

1 6'- 9"

Bed Sensor

1

2 7'- 0"

4 ft . 6 . 0 in . x 2 ft . 6 . 0 in . Activity Beacon U W

W

U

B 3

D3

Closet

4

Imed

C 1

6

Watch Charger

U

bdb F 1

U D 5

7

U

W

Closet

W

E 1

3

2

7'-2"

W U

W

Frige

Do U

4'- 0"

224

150 Do U

5 '-9 1 / 2 "

SENSORS 150 — DSFrontdoor 1 224 — DSFridge 1

4 '-5 "

Note : Base station would underneath the Bed Do Door Sensor U Motion Sensor U

W U

W

B 1— MSBedroom 1 B 3 — MSBedroom 2 E 1— MSBathhall 1 F 1— MSBathroom 1 D 5 — MSCloset 1 C 1— MSKitchen 1 D3 — MSLivingroom 1 D1 — MSLivingroom 2

Ceiling Motion Sensor Phone jack TV

Figure 6.1

6 '- 1 / 2 "

LOCATIONS 1 . Bedroom 2 . Bathhall 3 . Bathroom 4. Halldoor 5. Livingroom 6 . Kitchen 7 . Door

Cable Connection

Example of a floor plan with possible sensor locations.

5.

6.3.1

With participant representative groups in their homes (this is referred to as premarket testing). Bench Testing

Testing on the bench focuses initially on the individual devices. At this early stage, the devices may be prototypes made up of combinations of modules and test boards. This is sufficient to verify that the devices display their intended functionality. A test plan is drawn up for each device. The test plan consists of multiple tests, each one specifying the functional requirement being tested, the manner in which it is tested (the metric), and the process to be followed during testing. Typical tests will cover topics such as:

110

Deploying in the Field

• • • • • •

Radio functionality; Power management; Battery capacity; Memory; Actuator elements (lights, screens, LEDs); Sensor functionality (movement, temperature, etc.).

Test plans should be fully documented, and failed tests should be tracked using an issue management system such as BugZilla or Mantis. The software used in the device is tested as part of the device testing. 6.3.2

Lab Testing

A mock-up of a typical deployment environment should be used to carry out laboratory testing. The objective here is to ensure that devices, and the system as a whole, function as expected in an area approximately the same size and shape as a typical deployment location. As far as is feasible, the furniture, the human occupation, and other characteristics of the deployment environment should be replicated in the laboratory (Figure 6.2). The process for lab testing is to start with a single device, and then to introduce new devices one at a time. Each time a new device is added to the mix, the overall system functionality is tested, including regression testing to ensure that the introduction of the new device has not disrupted the functionality of the system as it was before the new device was added. A full test and validation plan documentation cycle is needed here, with each test recorded for each set of active devices. The devices at this stage will typically be example PCBs, rather than collections of modules and test boards used in the lab tests. Key issues to test in the lab include:

Figure 6.2

Example layout of laboratory.

6.3 Testing

111

•

• •

• •

Communications between devices and aggregators, including radio range and interference effects; Data flow, storage, and management; The ability of the aggregator to handle multiple parallel streams of heterogeneous data; Monitoring and maintenance software; Impact of furniture, human occupancy, and other features of the environment on the functionality of the system.

Where mobile (wearable or portable) devices are to be deployed, they can be carried around the lab and placed in different locations in order to assess their viability. For location sensors, the lab offers opportunities for establishing their effectiveness. Where issues or problems arise during lab testing, suitable changes must be made to the design and implementation and then regression testing must take place. 6.3.3

Friendly Environment Test

A “friendly” environment is a real-world (out-of-lab) deployment environment, lived in by a team member rather than by a subject. Typically, this will be the home of a team member. As far as possible, the architectural and construction materials profile of the friendly environment should match that of the deployment environment. The purpose of friendly environment tests is to assess the system in a “real-world-like” environment over a protracted period. The focus of the tests includes: • • •

•

• •

Long-term stability of hardware and software; Long-term communications and data capture functionality; Architectural and built environment factors, particularly in terms of their effect on radio communications and sensor function; Impact of furniture, microwave ovens, and other sources of radio waves (e.g., WiFi networks); Impact of heat, cold, humidity, and other environmental factors; Need for form factor changes, to better fit into real-world environments (Figure 6.3).

By carrying out the tests in a friendly environment, the project can easily and rapidly change and improve the system, without imposing on a subject. 6.3.4

Ethical Review and Labeling

At this stage of the testing, the technology is ready to be deployed outside the controlled environment, and to become “customer-facing” for the first time. Before this can happen, the system must pass through ethical review and scrutiny by a human subjects review board. The objective of this process is to apply medical ethics guide-

112

Deploying in the Field

Figure 6.3

Example of form factor change: modified sensor on refrigerator door.

lines to the testing and to ensure that the users who are involved in the testing will not be exposed to harm. The review process includes a requirement for a full protocol description of what the testing team will do, and a risk assessment for each device and each actuator. An additional safety and regulatory step is the correct labeling of all devices. It must be clear to the users of the devices that while these devices are being used in a medical/clinical/research context, they are not approved medical devices and have not been authorized by the FDA, the EU, or other regulatory bodies. The FDA [1] recommends that labeling for electrical and electronic medical devices, such as those containing wireless technology, should include: • •

• •

Equipment or system specifications; Electromagnetic compatibility (EMC) and telecommunications standards compliance or other testing performed; EMC and telecommunications standards test results; Warnings about possible effects on the labeled device of RF sources (e.g., security systems, cell phones, PDAs, other in-band transmitters).

The FDA recommends the labeling include: • • •

Recommended separation distances from other devices or EMD sources; Conformance to existing standards; How testing was conducted;

6.4 Preinstall

•

113

Any susceptibilities discovered.

While labeling is essential prior to premarket testing, it is best practice to begin to label devices in this manner during the lab testing phase. 6.3.5

Premarket Testing

The final stage of testing involves installing and running the entire system in the homes of a number of subjects. These subjects are recruited from within the population that the technology is meant to serve—they are older persons, living alone. The objective here is to identify usage issues and technical issues that have not arisen in the laboratory or friendly environments. A particular focus is on the use of the system devices in a manner other than that anticipated by the design team, thus overcoming assumptions and usage bias. During premarket testing, the full deployment process, from planning to teardown, is carried out, just as it will be when the system is finally deployed in the field. Issues or adjustments to the process which are identified in this premarket testing process lead to adjustments in the final deployment process. 6.3.6

Documentation

All stages in the testing should be fully documented by the test team, and made available to the deployment teams on the project. This documentation should include information on lessons learned, as well as problems that arose and solutions that were found. These reports can act as frequently asked questions lists and as guidance to the deployment teams; they identify many of the issues that may arise during wider deployment, and the approaches used to solve these issues. Note that when devices are replaced or modified during the course of the project, they should be fully tested before being installed. Improvisations can lead to unexpected issues, impacting on the overall project and leading to repeated maintenance visits to the subject’s home.

6.4

Preinstall Before actually traveling to the home of the subject and installing the WSN, the engineer should carry out a preinstall phase. The aim of this phase is to make the following (installation) phase as smooth as possible. The key points here are as follows: 1.

Contact the subject and agree the date and time for installation. This is the first direct contact between the engineer and the subject, and is key to a positive relationship in the future. Allow extra time for the installation process, in order to minimize impact at the time of installation. If the subject prefers to have a third party (e.g., a caregiver) present, make allowance for this.

114

Deploying in the Field

2.

3.

6.5

Build the entire house WSN, including aggregator(s) and server(s), in the laboratory and run it overnight before the installation. This will help to identify any last-minute issues, which can be addressed prior to the install process itself. It will also serve to ensure that all components are available. Prepare an install pack, with the full set of technology, plus spares. Additional enclosures, power sockets, and other cosmetic elements may also be included here, in order to support a level of flexibility during the installation.

Installation An important factor for the installation phase is that it is “customer facing”—the team is dealing directly with the subject, in the subject’s own home. It is essential that the team build an appropriate relationship with the subject, remaining respectful and professional at all times. Asking permission before entering a room, moving furniture, or otherwise changing the environment is important. A good relationship will bear fruit in the future, if and when maintenance or changes to the system are required, and the forbearance and patience of the subject is needed for success. The key steps for the installation are outlined below. Note that there should be full agreement on all aspects of the installation, before any toolboxes are opened or hardware installed. 1.

Introduce the team and remind the subject of recent (telephone or other) contact. Outline the work that will be done, the timescale for the project, and the commitment of the team to minimizing the impact on the subject. 2. Discuss the ideal locations for sensors with the subject, and seek agreement on locations. 3. Locate and identify studs and other construction elements that impact on sensor location. Identify warm and cold spots, sources of humidity or damp, and so forth. 4. Agree on a location for the aggregator (laptop, server, smart phone, etc.). 5. Agree on the power supply to be used, and the sockets available. Seek to minimize the impact on the use of sockets. 6. Bear in mind the need for access for maintenance purposes—aim to have sensors and other technology accessible from floor level whenever feasible. 7. Mark the locations of all elements with removable markers (e.g., post-it notes) and agree on them with the subject. 8. Install the devices, aggregator, and so forth. 9. Verify that the WSN is operating as intended, using the online maintenance/monitoring software. 10. Check that data is being generated and collected as intended. 11. Where there is any wiring, ensure that it is tidy, ideally boxed-in, and does not introduce opportunities for accidents or for the unintentional disconnection of technology (Figure 6.4). 12. Discuss with the subject the correct wearing, carrying, or use of mobile sensors, actuators, and aggregators (Figure 6.5).

6.6 Maintenance

115

Figure 6.4

Example of wiring, demonstrating need for enclosure.

Figure 6.5 air.

Laptop aggregator with ridged foam enclosure to ensure free circulation of cooling

13. Demonstrate any actuation functionality and ensure that the subject fully understands its intention. 14. Alert the subject to the possibility that maintenance will be required, particularly in the first weeks as the system “beds in.” Agree on a process for scheduling maintenance visits. 15. Make support and contact details available to the subject. Leave a written record in an agreed location. Having completed the installation, ensure that the environment is left as tidy and unaffected as possible.

6.6

Maintenance The WSN is likely to require maintenance during the course of the project. It should also be monitored on an ongoing basis, in order to verify that it is functioning as planned.

116

Deploying in the Field

The use of maintenance software, which monitors and reports on the functionality of the devices in the WSN, is essential. Ideally, this software should be accessible and configurable online; this enables the verification of a correct installation during the install process, and also facilitates the individuals who are responsible for maintenance (Figure 6.6). The use of issue-tracking software such as BugZilla or Mantis can be recommended for following up on maintenance issues. On an ongoing basis, the team should ensure that data is being collected, stored, and backed up according to plan. The WSN is installed out-of-lab; the possibility of data loss due to hardware failure or some other external event should be taken into account when planning a backup/recovery process for the project data. In the event that issues with the WSN require a return visit to the subject’s home, an appointment should be made in the manner agreed at install time. The appointment should be adhered to, and the existing professional relationship maintained. Even where repeated visits are required, it is important not to disillusion the subject regarding the value of the WSN, as this can lead to lack of use, thus undermining the value of the work. During maintenance work, explain the issue to the subject, if he or she is interested, and seek to secure the endorsement of the subject for whatever repair process is planned.

6.7

Teardown At the end of the project, it may be necessary to return to the subject’s home and remove the WSN. The key issue here is to minimize the mess, noise, and impact of

Figure 6.6 houses.

Example of maintenance software: the dots are color-coded to indicate the status of

6.8 Field Experience

117

the removal process, and to leave the subject with a generally positive impression of involvement in the project. The following points apply: 1.

2.

3.

4. 5.

6.

6.8

Agree and adhere to the appointment: as usual, minimize the inconvenience for the subject. Allow ample time for the removal of the WSN, and for any adjustment or repair to the environment or décor that the removal of the WSN will require. Minimize time and impact of teardown process: in so far as is possible, aim to complete the process rapidly and quietly. As usual, maintain the professional and respectful relationship with the subject. Ensure that décor is unaffected: where décor, furniture, or ornaments need to be moved or replaced, consult with the subject and ensure that he or she is completely happy with the end results. Provide subject with ongoing contact details: if the subject wishes to contact the project team in the future, this should be facilitated. Explain whether/what other followup may occur: if the project team plans to contact the subject again, outline how this might happen and ensure that the subject is happy to be contacted. Give opportunity for feedback: formally request feedback or comments; take note of any input from the subject and take it into account in the future.

Field Experience The following sections include examples of how the process was applied in realworld deployments, and also the experience that led to several of the points made in this chapter. 6.8.1

Planning

A key issue for planning is the layout of the deployment environment (the subject’s home) and the identification of ideal sensor locations. The ideal sensor locations reflect the range of the radios being used (e.g., ZigBee, Bluetooth), the size of the rooms, the sensitivity of motion sensors, and so forth. Figure 6.7 shows an example floor plan with sensor locations. The sensor locations must be verified and validated after the installation to ensure that data is being captured and communicated as planned. 6.8.2

Choice of Radio

The choice of radio technologies can have a profound impact on the success of communications within a project. Similar devices from different suppliers may perform in dramatically different ways. Intel PRI Europe team carried out an extensive testing in various homes to test the reliability of a range of Bluetooth dongles in each home. Their tests were centered on:

118

Deploying in the Field

LV3A

Office motion

N bed

motion

Living

Bath

Master lamp

motion

chair

Laundry motion

MBath

motion

Garage

Kitchen mat motion

Dining

Figure 6.7

• • • •

Example floor plan.

Evaluation of Bluetooth Class 2 and Class 1 device performance in homes; Seven typical homes were surveyed; Five commercial Bluetooth dongles; Sources of RF interferences.

The goal of the research was to investigate the impact of the following: • • • • •

Types of houses (e.g., size, age, construction materials); Type and quality of Bluetooth radio; Node location; Interference from electrical appliances; Interference of other 2.4-GHz sources such as 802.11b/g access points.

Figure 6.8 shows a sample test done by the team. The test was conducted by using a Bluetooth sensor unit as a mobile device and moving it around the home. The base station was a laptop connected to a Bluetooth sniffer and to various Bluetooth dongles. The distances of sensor unit to the base station were recorded in each home, while taking notes of the building type, materials built with it, environmental conditions, and so forth (see Figure 6.9). The team was able to prove from their experiment that Bluetooth dongles with external antenna were the most reliable form of dongle to deploy in an uncontrolled environment. This result also proved to be the case in the CAMP project. Figure 6.10 shows the results of the Bluetooth dongles used in the test.

6.8 Field Experience

119

Bluetooth sniffer Frame analyser Sensor unit

2345 4546 7834 8753 3573 4546 9932 4549 2394 2324

Sensor data

Bluetooth receivers internal and external antenna Hyper terminal

Figure 6.8

Overview of experiment.

Figure 6.9

Layout of home for experiment.

120

Deploying in the Field

Distance (M) Variance Std Deviation

Figure 6.10 Experimental results of the Bluetooth dongles from the team. Note that the dongles are arranged in the order of graphical display of the distances.

6.8.3

Installation

It is important to mark and agree on the location of each sensor with the subject. In addition, it should be as easy as possible to remove the sensor during teardown, while minimizing the impact of the project on the décor of the subject’s home. Double-sided 3M picture-hanging tape was found to be ideal for placing and holding sensors in one deployment (Figures 6.11–6.13). 6.8.4

Building Materials

A friendly environment trial was carried out in Portland, Oregon, for the wireless sensor network to determine social health and effects of depression on elders. In the northwest of the United States the homes are mostly constructed of timber, cedar siding, and sheetrock on supported floors. Most of the problems in system reliability had been resolved in the friendly trial. However, during the first installation of the premarket trials, in Nevada, the system failed to operate in the home of the client. After investigation, it was found that the environment had substantially changed from the friendly trials. The sensors were not being received at the base station. Upon further investigation the discovery was made that the homes in the southwest suffer from massive termite infestation coupled with the high cost of transporting the timber into the desert of the southwest. To mitigate these issues in home construction, builders used galvanized steel frames, steel doors, and constructed with masonry block coated with stucco. Stucco is applied by fixing a wire mesh to the masonry and spreading a paste over it. Additionally the southwestern states have numerous thunderstorms throughout the year, commonly with lightning. Due to lightning, the builders in the southwest typically ground all metal in the construction to a metal stake driven into the ground.

6.8 Field Experience

Figure 6.11

Tape on the wall.

Figure 6.12

Tape holding sensor in place.

121

As most engineers can now see, what is being described is a Faraday cage disguised as a house. Since many of the interior walls in the home also contained similar construction, the sensors’ transmission energy in the friendly trials was insufficient for the environment in the end customer’s home.

122

Deploying in the Field

Figure 6.13

6.8.5

Tape holding heavy activity beacon device.

Participant Tests

In the course of the CAMP project, a pillbox with sensor-equipped doors was deployed (Figure 6.14). Each time a door in the pillbox was opened, a signal was sent to the aggregator, indicating that a pill had been taken. However, one subject left the door open, as a reminder to himself to take the second pill; this was not as envisaged by the team, and led to unexpected inferences by the system.

Figure 6.14

Pillbox.

6.8 Field Experience

6.8.6

123

Human Frailty

The subjects of any WSN installation are older persons, living alone. Often they will suffer from medical conditions, such as vulnerability to falling, reduced cognitive performance, or mild dementia. There is a very real possibility that during the lifetime of the project, the condition of some of the subjects may deteriorate to the degree that they can no longer take part in the project. Ideally, the project team should have a reserve list of subjects available. 6.8.7

Fluorescent Lamps and Infrared

Common fluorescent lighting fixtures driven by electronic ballasts emit lowfrequency infrared signals modulated in the kilohertz range. This signal interferes to a very significant degree with infrared communications between devices and aggregators, or among devices [2]. This needs to be taken into account when choosing the technologies to deploy, and also when positioning devices in the home. Bear in mind that some applications of fluorescent lights mean that they are used only occasionally—for example as lighting over kitchen counters.

References [1] [2]

Draft Guidance for Industry and FDA Staff: Radio-Frequency Wireless Technology in Medical Devices, released Jan. 3, 2007, http://www.fda.gov/cdrh/osel/guidance/1618.pdf. Narasimhan, R., M. D. Audeh, and J. M. Kahn, “Effect of Electronic-Ballast Fluorescent Lighting on Wireless Infrared Links,” Proc. IEEE International Conference on Converging Technologies for Tomorrow’s Applications (ICC ‘96), Dallas, TX, June 1996, Vol. 2, pp. 1213–1219.

CHAPTER 7

Clinical Deployments of Wireless Sensor Networks: Gait 7.1

Introduction This chapter is the first of three case studies, where we look at how the process outlined in the earlier chapters is actually used in the field. These case studies follow recent research projects in the clinic and/or the home, and show how the process was applied. An important lesson is that not all the steps described earlier in this book need necessarily be taken in any one project, but that the overall progression from initial requirements statement to new knowledge is the same. The case study in this chapter presents a technology trial project that focuses on an important clinical objective, the association of certain gait parameters with particular disease states [1–36].

7.2

Clinical Problem Statement Elderly suffering from falls in their homes are a crucial concern for researchers in the area of independent living. Falls are the most common cause of injury and one of the principal causes of death and disability in older persons. Forty-five percent of older persons who sustain a hip fracture from a fall never achieve their previous level of independence and one third die as a result of the injury. Moreover, the recurrence of falls is a common reason (40% of cases) for admission of previously independent elderly persons to long-term care institutions. Even noninjurious falls have significant negative consequences for the individual because of fear of falling, functional deterioration, anxiety, depression, and loss of confidence and hence independence. There is evidence to suggest that if fallers are not identified and are not treated early enough they pass a threshold after which interventions for risk factors are inadequate to reduce further falls and prevent a cascade of inevitable decline, loss of independence and eventually institutionalization. Thus, early detection for falls risks is of significant importance. Gait variation is an important indicator of vulnerability to falls. Erratic changes in speed, period, gait width, and pressure distribution across the foot all indicate a prediposition to a potential falls risk. In addition, gait variables are important indicators for several degenerative diseases, including Parkinson’s and arthritis. Improved measurement and analysis of gait information thus has significant clinical, diagnostic, and therapeutic value.

125

126

7.3

Clinical Deployments of Wireless Sensor Networks: Gait

Clinical Research Objective The initial clinical research aim of the project was established and agreed by a multidisciplinary team. The team was made up of clinical researchers and engineers from Intel Corporation’s European product research and incubation team (based in Ireland), working together with clinical researchers from Irish universities in a collaborative research initiative called the Technology Research for Independent Living Centre, or TRIL Centre. The aim of this study is to identify the key postural and neurocardiovascular characteristics unique to fallers; to develop new technologies for monitoring, feedback and intervention; and to create new algorithms for early detection of fall risk. The first phase of this study identifies the postural and neurocardiovascular characteristics of 300 elderly subjects in a clinical setting using the TRIL Centre Gait Analysis Platform. This research platform integrates a wide range of sensor types including video cameras, body-fixed motion sensors, a pressure sensitive floor sensor, as well as EMG, ECG, and GSR sensors. This data will be analyzed to find markers of gait and the other biometric measurements, which may indicate a predisposition to a particular degenerative disease. A truly holistic description for the disease state through gait can be achieved using combination of these gait and physiological-metric markers. Thus the holistic description becomes analogous to a fingerprint for a disease state. At the end of this project, a disease diagnosis system, to measure these fingerprints, will be developed for use in a home environment. This system will be nonobtrusive so as not to interfere with a patient’s daily routine or their sense of independence. The system will gather relevant data from an array of sensors and will communicate the associated data to a computer network. The system will provide doctors with the capability to monitor their patients in their homes for prolonged periods of time without the doctors having to leave their working environment.

7.3.1

Technology Objective

In the context of this clinical background and objective, the project established its technical objectives, expressing the aims of the team from a technology perspective. The literature indicates that three main types of technology have been used for gait modeling—floor mats, wearable sensors, and video. Typical research efforts have focused on combining and/or comparing any two of these, enabling researchers to establish whether or not the same data can be captured with different technologies, and also to establish differences in the data captured. The technical objectives of the project are to correlate sensor, video and floor-mat data, in order to: •

•

Establish which combinations of technology suffice to collect the maximum amount of gait information; this will be valuable information for future home deployments. Establish the ideal set of sensors and locations on the body, to collect the maximum amount of information about gait, with the minimum number of sensors.

7.4 Clinician Requirements

•

•

7.4

127

Create a 3-D matrix of sensor, video, and floor-mat information for each of 300 subjects. The subjects will also undergo clinical assessment in parallel with the study, and their disease state will be characterized. This will allow the project team to associate a particular disease state with a particular matrix of technology values—a fingerprint for the disease state. ECG, EMG, and BP sensors will also be applied at the same time, adding more depth to the information matrix. Track disease progression in terms of technology readings. As the same subjects return on a periodic basis for reassessment (both clinical and using the technology solution), new data points for the signature model will be collected.

Clinician Requirements The clinical requirements document, or CRD, outlines the medical background of the project, its clinical aims, the experimental protocols to be followed, the data to be collected, environmental factors, and so forth. This is explored in some detail in Chapter 3. The following is a simplified version of the CRD for this project, drawn up by the clinical and engineering teams. 7.4.1

User Definitions and Permissions

What category of end user will interact with this solution (e.g., trial clinician, analyzing clinician, general clinician) and what is their role (e.g., trial clinician runs the trial, analyzing clinician performs detailed analysis of data, general clinician monitors the data in an unspecified way) (See Table 7.1)? Table 7.1

User Role Definitions from CRD

User

Role

Subject

Is monitored by the system.

Therapist

1. Sets up and runs the trial. 2. Views results on GUI. 3. Performs long-term analysis within and between data sets.

Clinician

Designs trials.

Biomedical engineer

Designs and creates functional blocks.

Platform development engineer

Develops hardware and software platforms.

How will each user interact with the software and what are the general requirements of each end? (See Table 7.2.)

128

Clinical Deployments of Wireless Sensor Networks: Gait Table 7.2

User System Interactions Role Definitions from CRD

User

Interaction with Software

Subject

No interaction.

Therapist

1. Insert\retrieve patient data. 2. Start\stop trial. 3. Save data. 4. Views results on GUI. 5. Analysis of data sets. 6. Print reports.

Clinician

1. Designs trials by selecting to use existing functional blocks. 2. Designs GUI interface to trials.

Biomedical engineer

Designs data analysis blocks. Creates functional block sets.

Platform development engineer

Develops hardware and software platforms.

7.4.2

Clinical Parameters

What subject data needs to be collected and in what form (paper/ electronic)? All data will be saved electronically (Table 7.3). What parameters need to be measured and at what resolution (e.g., motion, time-on-task, stress, room temperature, daily)? (See Table 7.4.)

Table 7.3

General Subject Data and Medical History Requirements from CRD

Data

Details

Data Type

Name

Name and surname

Text

TRIL ID

Automatically generated ID

Text

trightMRN

Hospital patient ID

Text

Age

Date of birth

date

Height

Centimeters

Integer

pnumWeight

Kilograms

Float

Shoe size

Millimeters

Integer

Hip-height

Millimeters

Integer

Medications

For each medication: Dosage Frequency Comments

Text box for Dosage Frequency Comments

Falls risk

Fallen before (yes/no. If yes—number of times fallen? Most recent fall?) Result from BERG scale

Fallen before—check box Number of falls—drop list Most recent fall—date BERG scale-integer

7.4 Clinician Requirements

129

Table 7.3 (continued) Data

Details

Data Type

Patient history and clinical status

Drop menu Parkinson’s Stroke Osteoarthritis Cognitive impairment Others (text box to specify)

Assistance

Drop menu Independent Contact guard Assist of 1 Assist of 2

Mobility device

Drop menu Independent Stick Tripod Zimmer Rotator

Table 7.4

Kinematic Data Definitions and Acquisition Rate Requirements from CRD

Parameters

Resolution

Data Type

Bilateral stride time

50 Hz (5 ms)

Float

Bilateral stance time

50 Hz (5 ms)

Float

Bilateral swing time

50 Hz (5 ms)

Float

Bilateral stride distance

1 cm

Float

Bilateral stance distance

1 cm

Float

Bilateral swing distance

1 cm

Float

Step width

1 cm

Float

2-D knee joint angle

Sampled at 50 Hz, 5-degree

Float

resolution Torso tilt

Sampled at 50 Hz, 5-degree

Float

resolution 2-D ankle joint angle

Sampled at 50 Hz, 5-degree

Float

resolution Head tilt

Sampled at 50 Hz, 5-degree

Float

resolution EOG

Float

What is the standard duration of each trial and at what intervals does it occur (every second, once an hour)? An example would be three get-up-and-go walks along the floor sensor (one at normal speed, one at quick pace, one at normal pace).

130

Clinical Deployments of Wireless Sensor Networks: Gait

What will/should the user be doing as the information is gathered (talking on the phone, watching TV, walking outdoors)? An example would be walking along the floor sensor. How much can/should the subject be aware of the measurement system (e.g., fully aware, I want them to perform a particular action; partially aware, they can be wearing or carrying a sensor; completely unaware, the measurement must be embedded in the environment)? An example would be partially aware (they will be wearing sensors and walking). 7.4.3

Data Collection and Storage

How should data from the trial be saved (e.g., a single file after initial processing, multiple files in single folder, multiple files in subfolders, in a database table)? An example would be multiple files in a single folder. How should files from different subjects and different trials be distinguished (e.g., file naming convention, folder for each user/each trial, header within each file)? An example would be: • • •

Subject name/ID; Trial name; Date.

7.4.4

Data Analysis and Reporting

What information is required from these measurements (variability of gait, sudden change in stress, lack of arousal)? 1. 2. 3. 4. 5. 6.

Gait variability; Gait instability; Heart rate; Respiration; Stress; Fatigue.

Does this information need to be customized to the individual? Yes, as these factors will vary according to age, build, and clinical status. What data should be displayed in real-time (e.g., video, pressure, horizontal acceleration) and how should it be presented (e.g., graphs, data stream)? (See Table 7.5.)

7.4 Clinician Requirements

131

Table 7.5

Real-Time Data Display Requirements from the CRD

Data

Display

Real-time unprocessed video

Video

Real-time foot pressure

2-D graph

ECG

Streaming graph

Unprocessed acceleration

Streaming graph

What data would be useful to view after the trial and how should it be presented (e.g., vertical and lateral acceleration)? (See Table 7.6.) At what intervals should data be collected (e.g., real-time, hourly, daily)? Data should be collected continually at the frequencies listed in Table 7.4 throughout the trial. Are alerts required during the data collection process? What should these alerts indicate? Not applicable. Will all the data be analyzed using the BioMOBIUS application or is there a preferred software tool for the analysis of certain data sets? Preliminary processing should occur on BioMOBIUS. The therapist should have the option of exporting raw data and\or processed data to Excel spreadTable 7.6

Format Definitions fro On-Screen Parameter Display from CRD

Parameters

Presentation

Bilateral stride time

Text (average and variability of stride time for left and right feet)

Bilateral stance time

Text (average and variability of stance time for left and right feet)

Bilateral swing time

Text (average and variability of swing time for left and right feet)

Bilateral stride distance

Text (average and variability of stride distance for left and right feet)

Bilateral stance distance

Text (average stance distance for left and right feet)

Bilateral swing distance

Text (average and variability of stride distance for left and right feet)

Step width

Text (average and variability) of stride distance)

Swing kinematics of knee

Text (average and variability of swing kinematics for left and right knees)

Torso kinematics

Text (average and variability of torso kinematics)

Ankle kinematics

Text (average and variability of swing kinematics for left and right ankles)

Head kinematics

Text (average and variability of head kinematics for left and right feet)

EOG

Text (average and variability of ocular motion)

Foot pressure distribution

Text (average and variability of heel-strike and toe-off pressure)

Bilateral muscle activity

Text

GSR

Text

Heart rate

Text (average and variability of heart rate)

Respiration

Text (average and variability of respiration motion)

132

Clinical Deployments of Wireless Sensor Networks: Gait

sheets for analysis with SPSS. Additional processing with MATLAB will also be possible. 7.4.5

Subject Interaction

What information should be reported to the subject? Do new interactions have to be created (e.g., the subject is required to answer questions on screen, the subject needs to respond to a particular sound, the subject has to read data on screen)? Distractions maybe integrated into the system at a later date. What alerts or events need to be created? Not applicable.

7.5

Ethnography and Usage Modeling A number of key ethnographic observations informed the requirements specification. These included the following: •

•

•

•

•

No subjects were happy to be video-taped on an ongoing basis. This was an important driver for the project—a sensor-based solution was needed that could gather and analyze similar levels of data to a video-based system. The majority of older people are women; this reflects the longer life expectancy of females in western society. Ladies’ clothes typically do not have pockets or belts that can be used to contain or hang sensors (women’s pockets are not for filling). Shoes were also not a suitable host environment for sensors, because of the difficulty of forecasting which pair of shoes would be worn, as well as the variety of form factors. Subjects prefer not to wear or carry sensors that have no function other than to act as a sensor. Integrating the sensor functionality into a device that also does something else, such as a watch or a mobile telephone, greatly increases the willingness of the subject to comply with the sensor regimen. While subjects expressed a preference not to carry or wear sensors that had no other function, they are actually prepared to comply with any reason sensor regimen, if the benefits are sufficiently great, or the potential downside is sufficiently severe. Subjects walked with better posture during clinical trials than perceived by ethnographic observation in the home environment. This is an example of “white coat syndrome.” In the home, participants tended to use furniture for additional support. This introduces an additional level of uncertainty in the clinical measurements.

7.6 Environmental Issues

7.6

133

Environmental Issues The environment in which this system is being deployed is a single room in the laboratory and the friendly clinic. The key environmental issue is that the deployment is in a hospital environment, therefore the wireless communications must not interfere with other devices in the vicinity. Note that in a home environment there is a greater need for low-power operation and less focus on radio interference; in such a case, a different radio solution might apply.

7.7

Technology Selection Criteria The choice of technology is driven by the data that is to be collected. The research core of the project is the collection, combination, and cross-analysis of accelerometer, footfall, and video data. Various different configurations of sensor will be required. Very fine-grained footfall information will be needed, in order to fully capture the dynamics of pressure distribution across the sole of the foot during the walking process. The selection criteria are thus: Sensor Device •

•

•

• •

•

Six degrees of freedom are needed, so that a full 3-D picture of the movement of each sensor can be developed. The sensor device must be small and light enough to be worn anywhere on the body or limbs, without restricting movement or affecting the gait. The sensor device must be easily reconfigurable for different subjects and to collect new data. The device must be self-powered, so that the subject is not trailing wires. The device will be recharged after each use, so low-power consumption is not a priority in the clinical environment; however, a low-power platform is to be preferred to allow for easy migration to the home environment. The device must be able to rapidly collect and transmit data, at high sampling rates.

Radio •

•

•

•

The device must communicate significant amounts of 3-D data in real time. The range required is short—the gait analysis system is all within a single room. The radio must not interfere with healthcare devices elsewhere in the clinic (802.15.4 is thus not preferred). The device is recharged after each use, so low-power radio is not a priority in the clinic; if a home deployment takes place, a lower-power radio stack such as ZigBee/802.15.4 may be appropriate.

134

Clinical Deployments of Wireless Sensor Networks: Gait

Footfall Capture

A footfall mat is required. The selection criteria are: •

•

•

•

What to sense: footfall pressure distribution. There is no requirement for heat sensors, pulse, and so forth. Sensitivity: maximum possible sensitivity and density of sensors, to capture all available data. Interface: the footfall mat must interface with a PC running the gait analysis software. High sampling rate: data must be collected in real time.

Video •

•

Two video cameras are needed, set up orthogonally to one another, in order to capture all elements of movement. The video capture must interface to the PC running the gait analysis software.

Aggregator •

•

•

A single PC-based aggregator and data analysis server is sufficient for this project, due to the fact that the gait analysis takes place in a single location. The PC must interface with the device radio stack, the footfall sensors, and the video. The PC must run the software, as outlined below.

Software

The software needed for the system must be capable of: • • •

• • • •

7.8

Real-time analysis of the incoming data. Integrating and displaying the data from sensor, mat, and video sources. Adjusting operating parameters (e.g., frame rate, sampling rate) of the hardware. Being easily changed and adjusted in response to evolving research aims. Personalization for each subject, as necessary. Recording additional arbitrary notes and other data created by the clinician. Supporting long-term data storage.

Technology Selection Based on the selection criteria above, the following technology were chosen for the project.

7.8 Technology Selection

7.8.1

135

Device

A key feature of this system is its ability to measure multiple parameters simultaneously, without impeding the natural movements of the monitored subjects. This feature has been made possible by the development of a wireless sensing platform, known as SHIMMER, which can be attached to any part of the body for the measurement of motion, heart rate, muscular activity, and other physiological parameters. SHIMMER is a radio agnostic platform that can communicate using any industrial, scientific and medical (ISM) band wireless technology, but comes equipped with Bluetooth and 802.15.4 stacks. It is also sensor agnostic: it can operate with any sensor connected to the baseboard. SHIMMER is built on the Texas Instruments MSP430 microcontroller. The MSP430 contains 10 Kb of RAM, 48 Kb of Flash, and 128 bytes of information storage. Additional storage is available via a micro-SD slot on the SHIMMER baseboard. Both internal and external expansion capabilities are built in, in order to allow SHIMMER to be repurposed and reused in a range of applications. 7.8.2

Sensor Technology

Several sensor technologies are available as add-ons to SHIMMER either as add-on daughterboards or interfaced through SHIMMER’s analog extender (AnEx) breakout board. These include: • • • • • •

Triaxial accelerometer; Triaxial gyroscope; Electrocardiogram (ECG); Electromyograph (EMG); Electroencephalograph (EEG); Galvanic skin response (GSR).

Figure 7.1 illustrates the SHIMMER platform with various add-ons and enclosures. 7.8.3

Radio

All measurements are transmitted via a wireless Bluetooth link with a range of 100m (330 ft) line-of-sight and 30m (100 ft) indoors. This has the advantage of high bandwidth and the ability to hop between frequencies in order to minimize interference. The Bluetooth device (Roving Networks RN-41) supports super-low power usage in deep-sleep mode, as well as three other modes of operation; this makes it very suitable for deployment in a wearable or mobile sensor environment. 7.8.4

Footfall Mapping Technology

The footfall data collection system has a total sensing area of 2 ½×15 feet on a vinyl tiled walking surface over seven Tactex “large array sensors,” each of which is 26×28 feet, mounted in the subfloor. The thickness of the floor system including subfloor, sensors, and walking surface is approximately 2 feet. The interface is a

136

Clinical Deployments of Wireless Sensor Networks: Gait

(e)

(a) (f)

(b)

(c)

(d)

Figure 7.1 SHIMMER with add-ons. (a) Shows one half of an ECG enclosure unit that contains plug-in connections for the right arm, left arm, and left leg signals, (b) corresponds to the SHIMMER baseboard, (c) is the analog extender (AnEx) breakout board that plugs into the external expansion connector, (d) illustrates the electrocardiogram (ECG) expansion board, (e) corresponds to the kinematics gyro sensor board, and (f) illustrates the clear-fronted reference enclosure.

custom interface module combined with commercial serial-to-USB hubs to connect the sensors to the PC. (Note that the length of the footfall mat meant that several Tactex component systems had to be joined together and for large numbers of power supplies, one for each Tactex component.) 7.8.5

Video Cameras and System Layout

Two video cameras with in screen clocking systems are used in the experiment to capture video of the gait and motion to help in calibrating and analyzing the data. The two cameras are mounted on tripods with orthogonal fields of view. The layout is shown in Figure 7.2. 7.8.6

Software

Data collection and analysis was implemented using the BioMOBIUS software development platform. This platform enables the creation of clinical applications through the combination of libraries of functional blocks in a graphical development environment. In this case, blocks that interface to floor sensors, to SHIMMER devices and to video were integrated into a single application. Data analysis, visualization, and clinician user interface components were also added (Figure 7.3).

7.9

Prototype Definitions Requirements Document A simplified PDRD for this system is shown here. It reflects the structure and scope outlined in Chapter 4.

7.9 Prototype Definitions Requirements Document

137

Field view for camera 2

Field view for camera 1

Floor mat from Tactex Camera 2

Camera 1

Figure 7.2

System layout.

7.9.1

Purpose of PDRD

Elderly falls in the home are one of the critical concerns of independent living. This study is focused on developing capabilities that will help predetermine degenerative diseases through abnormal gait identification, by creating a library of disease states using a sensor suite on the body in a clinical setting. This research will help to determine which sensors are critical to the development of a solution device that can be used for detecting the characteristics of gait that in turn can indicate the onset of degenerative diseases or a predisposition to falling. This study will integrate several systems together into a true six degrees of freedom analysis system that is linked to footfall data. This technique involves placement of multiple six degrees of freedom wireless sensors on the body to collect acceleration and angular velocity data at various points. Gait parameters can be extracted through implementation of appropriate algorithms. The acquired parameters are correlated to the footfall data collected from a floor mat sensor. Finally the footfall data and sensor data will be back correlated to video records of the subject under evaluation. Once the appropriate data has been collected the team will potentially have the capability to specify the correct sensor strategy required for gait analysis for any particular patient. (See Table 7.7.) 7.9.2 7.9.2.1

System Description: Footfall Sensor Requirements

The footfall sensor must be able to detect the heel-strike and toe-off events, which indicate a step. Each data sample must be time-stamped using a real-time clock to enable calculation of stride time (heel-strike to heel-strike), stance time (heel-strike to toe-off), and bilateral swing time (toe-off to heel-strike). The actual data rate was less than 20 Hz, which is a big problem for the extraction of the spatial and temporal parameters of gait.

138

Clinical Deployments of Wireless Sensor Networks: Gait

Figure 7.3

Integrated view of video, floor-mat, and motion sensor gait parameter data.

The location of each heel-strike and toe-off event must also be recorded to enable calculation of bilateral stride distance (heel-strike to heel-strike), bilateral stance distance (heel-strike to toe-off), bilateral swing distance (toe-off to heel-strike) and step width (distance between right and left foot) to a resolution of 1 cm. The sensor should also be able to measure foot pressure distribution, which is clinically useful for the evaluation of foot and gait pathologies. The footfall sensor must therefore be able to detect pressure in the range 30 psi → 82 psi, to detect heel-strike and toe-off events in adults weighing between 47.6 and 127 kg. The sensor must be powered from a mains frequency supply (220V–240V). There should be no more than two power cables and one data cable from the sensor. All internal cabling must be enclosed to avoid trip hazards. There should be a platform placed at the start and end the floor sensor, to ensure that the first steps, last steps, and steps associated with turning are not recorded (these steps are usually ignored during data analysis). This ensures the

7.9 Prototype Definitions Requirements Document Table 7.7 Feature

139

Gait Analysis System Components Definiton from CRD Purpose Key Requirements

Footfall sensor

Sensor to detect footfalls

Time-stamped pressure data

Location of pressure Pressure distribution Interface to PC Software to view pressure distribution Wearable sensor

Sensor to collect data on accel- Time-stamped motion data eration and angular velocity at Record six degrees of motion various points Wireless transmission of data Attachable to area of interest Lightweight (less than 1%–2% of subject’s body weight) Rechargeable batteries

Software

User interface to sensor data

Video cameras

Two video camera, in orthogo- Time stamped video of gait trials nal fields of view to record and time stamp motion and gait

Miscellaneous sensors

Additional sensors to supplement overall gait analysis

Data acquisition Data processing Data presentation/GUI Data storage and retrieval

Muscle activity Distraction parameters Anxiety parameters

optimum usage of the floor sensor, as the pressure data recorded by the floor sensor will only be midwalk data. The user should not be able to distinguish between the platform and the floor sensor, therefore the height of the platform should be the same as the height of the floor sensor and the same floor covering should be used on the floor sensor and platform. The sampling rate of the sensor should be 25 Hz. The pressure data must be streamed from the sensor to the PC, such that it can be sampled by the software developed for this system. The Windows-based application associated with the floor sensor should have the following features: • •

• • • •

Graphical display of the applied pressure on the mat; Data logging—opening and closing of log files synchronized with the start and stop of data collection; Graphical playback of *.log files; “Configure Pads” and “Pressure Test” options via on-screen menus; Ability to mark an event; Sensor and interpolated sensor data (interpolation in this context means the estimation of the pressure between Taxels (individual pressure sensors in the floor mat), based on reading from the surrounding Taxels);

140

Clinical Deployments of Wireless Sensor Networks: Gait

•

Real-time motion charts and event detection charts, which plot motion/events against time in line charts.

7.9.2.2

Design Choice

A custom built footfall data collection system from Tactex was selected for this study (see Figure 7.4). The Tactex “magic carpet” consists of six large sensor arrays (“mats”), arranged in two rows of three mats. The mats are covered by a “floor” of vinyl tiles, measuring 1,220×2,440 mm. The placement of the mats, under the vinyl floor is indicated by the black tape. The floor sensor is surrounded by a wooden frame, which houses the mats, electronic components, and the vinyl floor. The thickness of the floor sensor including subfloor, sensors, and walking surface is approximately 50 mm. The serial outputs of each mat are connected, via serial-USB hubs, to a single USB output, located on the right side of the floor sensor. The floor sensor is powered by six power plugs on the top right of the mat and six power plugs on the bottom right of the mat. These power plugs have an American 2-pin interface but can operate between 110 and 240V AC. The sensor is based on Kinotex tactile force sensor—a sensor that measures minute displacements due to forces applied on its surface. It is constructed of plastic fiber embedded in foam—it can be made to be flexible or rigid and can operate with soft surfaces or from beneath durable wear layers. The outputs from the mat (GUI and *.log files) are divided into “left” and “right” grouping for data processing reasons. Therefore, in order to view/analyze the entire floor, the left floor GUI and the right floor GUI must be activated. There are 44 force sensors, called Taxels, in each mat, resulting in a total of 264 Taxels in the floor sensor. The Taxels are divided into left and right groups, and the Taxels in each group are numbered 1 to 132. The complete Taxel map of the floor sensor is plotted in Figure 7.5.

Figure 7.4

Tactex floor sensor.

7.9 Prototype Definitions Requirements Document

141

Top Left

Right

Power and data sockets

Bottom Figure 7.5

7.9.3 7.9.3.1

Taxel map of floor sensor.

System Description: Body-Worn Sensors Requirements

The body-worn sensors must be able to measure rotation and acceleration in three axes (six degrees of freedom). The accelerometers must be sensitive enough to accurately detect the impact of heel-strike and toe-off. The data rate of the sensor communications interface should be at least 115 kbps. Each data sample must be locally time-stamped in real-time before being transmitted to its master/server (e.g., PC). This can be achieved using an RTC or hardware timer block. The processor must run at low-power when not in use. It must also be reprogrammable using a familiar programming language, such as C, embedded Java, or assembly language. It must contain a minimum of six channels of 12-bit ADC (three channels for the accelerometer and three channels for the gyroscope data). The batteries for the sensors must be rechargeable, using external mains-powered charging circuitry, and have the capacity to last for 12 hours of continuous operation.

142

Clinical Deployments of Wireless Sensor Networks: Gait

The sensor device must be able to communicate data, via a Class 1 Bluetooth link. This Bluetooth transceiver must be capable of full duplex operation near the human body without human body interference and should have sufficient range to cover a house and penetrate multiple floors. The device must be capable of having the base station at one side of house and the most distant sensor/actuator at the other side (approximately 30 feet). Issues of apartments, construction materials, and bodies in line-of-sight must all be evaluated. Since the ISM band is used for a variety of communications systems, the sensor network must coexist with other RF systems in the house, such as 802.11, wireless phones, and so forth. This can be achieved by using a V1.2 or above Bluetooth radio module, which supports AFH. The sensor devices must be wireless, nonintrusive and lightweight (weighing less than 1%–2% of subject’s total bodyweight, if placed on lower extremities) to ensure that the subject’s gait is not impeded (Figure 7.6). Each device must be easily attached to the area of interest on the body. The enclosure must have an external power switch to power the sensor on/off. Power status and data transmission status should be indicated using external LEDs. The enclosure must have an external socket for charging the battery. The enclosure should have room to fit batteries, two LEDs, a power switch, a charging socket, and the sensor itself. The overall enclosure size must be no greater than 60×40×25 mm.

Figure 7.6

Sensor devices on legs.

7.9 Prototype Definitions Requirements Document

7.9.3.2

143

Design Choice

The project used SHIMMER devices with the add-ons described in Section 7.8.2. 7.9.4

System Description: Software

The software application for this study is responsible for the following: • • • •

Data acquisition; Data processing; Data presentation via GUI; Data storage and retrieval.

It provides a graphical user interface to support clinical trials. It is extensible to support rapid integration of additional functionality and it should allow proliferation without licensing issues. The application is capable of simultaneously acquiring real-time data from the wireless sensors, the floor sensors (via a USB port) and the video cameras. The GUI should contain a connection-status indicator to show the user which sensors are connected. The application should provide a synchronization algorithm output to all sensor units. This data must be time-stamped by the RTC of the PC as they are received, to enable calculation of data latency. The application must also be capable of uploading off-line data, collected by data loggers. The clinician must be able to control when data acquisition begins and ends via the application’s graphical user interface (GUI). The application should contain an option to label data events. The clinician must be able to enter the following clinical data into the application, via the GUI: • • • • • • • • •

Age; Patient history; Medication; Clinical status; Risk of falling; Mental status; Miscellaneous; Height; Weight.

The application must be able to align the data from each source, using the RTC time stamp and have the ability to synchronize data that is sampled at different rates. It must be able to process the sensor data and the floor sensor data in real-time, and postprocess all other data. The application must be able to extract the following parameters from the recorded data: • • • •

Time of day; Day of week; Stride time (heel strike to heel strike) at 200 Hz (bilateral); Stance time (heel strike to toe-off) at 200 Hz;

144

Clinical Deployments of Wireless Sensor Networks: Gait

• • • • • •

•

• •

• •

• • • •

Bilateral swing time (toe-off to heel strike) at 200 Hz; Bilateral stride distance (heel strike to heel strike) at 1-cm resolution; Bilateral stance distance (heel strike to toe-off) at 1-cm resolution; Bilateral swing distance (toe-off to heel strike) at 1-cm resolution; Step width (distance between left and right foot falls) at 1-cm resolution; Swing kinematics at 1-cm resolution at 200 Hz mounted at upper and lower portion of lower leg; Torso kinematics at 1-cm resolution at 200 Hz mounted at lower lumbar region; Ankle kinematics at 1-cm resolution at 200 Hz mounted on top of foot; Head kinematics at 1-cm resolution at 200 Hz mounted on top or back of head; EOG (electrooculograph) for saccadic eye motion; Foot pressure distribution over time under each foot (bilateral) measured in static position; EMG (electromyography) measurement at 500 Hz bilateral; Galvanic skin response (GSR); Heart rate and heart rate variability (HRV); Breathing rate.

The application must also have a function to enable the calibration of the sensors to an individual subject, by recording the sensor placements before and after the trial. The foot pressure pattern, from the floor sensor, the leg, torso, and head motion, from the body sensors, must be displayed in real-time charts. The clinician must be able to view charts of the raw data (acceleration, angular velocity of individual sensor, pressure, EMG, GSR, respiration, video), derived data (velocity, displacement, relative rotation between two sensors) and combined data (e.g., video and pressure data) off-line. The clinician must be able to select which parameters he or she wishes to view and at what time interval (e.g., all of the data, only data recorded between minute 1 and minute 6) he or she wishes to view that data. The application will record the clinical and sensor data of several subjects, with varying pathologies, over an extended period of time. The application must be capable of long-term storage of data to support historical trend analysis for individuals, and cross comparisons between individuals with a common pathology/age group/medication history. The application will provide an option to normalize the data according to height, weight, or height and weight; to enable comparison between subjects. The application must be able to store, retrieve, and chart data for a single trial, a single subject (multiple trials), and a single pathology (multiple trials and multiple subjects). 7.9.4.1

Design Choice

The floor sensor data are currently captured and saved as *.log files using the Tactex software.

7.10 System Validation

145

The application was developed using MATLAB. This application can identify heel-strike and toe-off events; and calculate relative orientation, velocity, and displacement from the acceleration and angular velocity data obtained from the sensors. These data can be charted using the MATLAB based software, as shown in Figure 7.7. The software can also replay the *.log files recorded from the Tactex footfall mat and integrate video recordings of a trial with the analyzed data. The data from each trial is saved as *.log files in folders specific to that trial. 7.9.5

System Description: Video

Two video cameras capture the motion video of the gait and motion to help in the analysis of the data. The two cameras are mounted on tripods in orthogonal fields of view. The video data is streamed to the PC and synchronized with all other data. 7.9.6 7.9.6.1

System Description: Miscellaneous Sensors Requirements

Every sensor added to the system must have a time-stamping mechanism, to enable synchronization with the gait and video data. They must not impede the subject’s movement or alter their gait pattern by being excessively heavy or bulky.

7.10

System Validation The system was deployed in a clinical environment in a major hospital in Dublin, Ireland. Working collaboratively with medical and clinical researchers, the engineering team assessed the gait of in excess of 600 patients and control subjects. The underlying model was to compare the data gathered by the sensor mat with that aggregated by the wireless network of SHIMMER devices. The scope of this validation also included the software created by the team to consolidate and analyze the SHIMMER data. Data gathered by both sets of technology (the sensor mat and the SHIMMER network) can have results that are very similar. This leads to the conclusion that the network of SHIMMER devices can be used as a viable alternative to the sensor mat technology. SHIMMER has the significant advantage over the gait mat solution in that it can be reprogrammed and adjusted to reflect a wide range of clinical research needs, including the possibility of adjustment of sensitivity, sampling period, and data processing on the device. In addition, the SHIMMER solution can be utilized in a wider location context, for example throughout a house or apartment. This has the advantage that gait can be monitored for a longer time period, and in a wider range of circumstances, reducing the white coat syndrome that impacts on the objectivity and hence the applicability of the gait sensor mat data. From the clinical perspective, there is potential of gait analysis as a diagnostic and monitoring tool for cognitive decline. One patient (TRIL ID 10026) had clearly defined differences in key gait characteristics when compared to his peers. This patient suffered from Alzheimer’s disease. Another patient (TRIL ID 10023)

146

Clinical Deployments of Wireless Sensor Networks: Gait

(a)

(b) Figure 7.7

Calibrated accelerometer and gyroscope data, recorded for five steps.

showed a marked variation from the wider population in terms of his base support (gait width) values; this patient suffered from significant ongoing cognitive decline.

7.11 Conclusion

7.11

147

Conclusion In this chapter we looked at an advanced system for gait analysis. The potential research and medical value of this system is enormous—falling is a major cause of both institutionalization and mortality in older persons, and predicting vulnerability to falling is currently very difficult. The clinical focus of the project is reflected by the importance given to the clinical requirements in setting up the system. There is no home deployment planned, and so there is less emphasis on usage modeling and on ethnography than in some other projects. The choice of technology was critical; however, if the state of the art in research and knowledge is to be advanced, the most effective and comprehensive technology platform must be used. Hardware and software that can easily be reconfigured and adjusted in order to maximize effectiveness is an important enabler for research at this level—the SHIMMER device and the BioMOBIUS software platform saved the team a good deal of time, effort and budget. Subsequent validation of the SHIMMER solution in the field demonstrated that the data collected by SHIMMER and analyzed using the BioMOBIUS software led to results effectively identical to those created using the gold standard gait sensor mat. Clearly, the SHIMMER solution has significant advantages in terms of mobility and domain of application, as well as cost, over the gait sensor mat solution.

References [1]

[2] [3]

[4]

[5]

[6]

[7]

[8]

Aminian, K., B. Najafi, and C. Bula, et al., “Spatio-Temporal Parameters of Gait Measured by an Ambulatory System Using Miniature Gyroscopes,” Journal of Biomechanics, Vol. 35, 2002, pp. 689–699. Bourke, A. K., J. V. O’Brien, and G. M. Lyons, “Evaluation of a Threshold-Based Tri-Axial Accelerometer Fall Detection Algorithm,” Gait & Posture, in press, corrected proof. Breen, P. P., D. T. O’Keeffe, and R. Conway, et al., “A System for the Delivery of Programmable, Adaptive Stimulation Intensity Envelopes for Drop Foot Correction Applications,” Medical Engineering & Physics, Vol. 28, 2006, pp. 177–186. Bussmann, J. B. J., K. M. Culhane, and H. L. D. Horemans, et al., “Validity of the Prosthetic Activity Monitor to Assess the Duration and Spatio-Temporal Characteristics of Prosthetic Walking,” IEEE Transactions on Neural Systems and Rehabilitation Engineering, Vol. 12, 2004, pp. 379–386. Byrne, C. A., G. M. Lyons, and A. E. Donnelly, et al., “Rectus Femoris Surface Myoelectric Signal Cross-Talk During Static Contractions,” Journal of Electromyography and Kinesiology, Vol. 15, 2005, pp. 564–575. Byrne, C. A., D. T. O’Keeffe, and A. E. Donnelly, et al., “Effect of Walking Speed Changes on Tibialis Anterior EMG During Healthy Gait for FES Envelope Design in Drop Foot Correction,” Journal of Electromyography and Kinesiology, Vol. 17, No. 5, Oct. 2007, pp. 605–616. Clarke Moloney, M., G. M. Lyons, and P. Breen,et al., “Haemodynamic Study Examining the Response of Venous Blood Flow to Electrical Stimulation of the Gastrocnemius Muscle in Patients with Chronic Venous Disease,” European Journal of Vascular and Endovascular Surgery, Vol. 31, 2006, pp. 300–305. Clarke-Moloney, M., G. M. Lyons, and P. E. Burke, et al., “A Review of Technological Approaches to Venous Ulceration,” Critical Reviews in Biomedical Engineering, Vol. 33, 2005, pp. 511–556.

148

Clinical Deployments of Wireless Sensor Networks: Gait [9]

[10] [11]

[12]

[13]

[14]

[15] [16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[26]

Culhane, K. M., G. M. Lyons, and D. Hilton, et al., “Long-Term Mobility Monitoring of Older Adults Using Accelerometers in a Clinical Environment,” Clinical Rehabilitation, Vol. 18, 2004, pp. 335–343. Culhane, K. M., M. O’Connor, and D. Lyons, et al., “Accelerometers in Rehabilitation Medicine for Older Adults,” Age and Ageing, Vol. 34, 2005, pp. 556–560. Giansanti, D. G., Maccioni, and V. Macellari, “The Development and Test of a Device for the Reconstruction of 3-D Position and Orientation By Means of a Kinematic Sensor Assembly with Rate Gyroscopes and Accelerometers,” IEEE Transactions on Bio-Medical Engineering, Vol. 52, 2005, pp. 1271–1277. Giansanti, D., V. Macellari, and G. Maccioni, et al., “Is It Feasible to Reconstruct Body Segment 3-D Position and Orientation Using Accelerometric Data?” IEEE Transactions on Bio-Medical Engineering, Vol. 50, 2003, pp. 476–483. Godfrey, A., K. M. Culhane, and G. M. Lyons, “Comparison of the Performance of the activPAL(TM) Professional Physical Activity Logger to a Discrete Accelerometer-Based Activity Monitor,” Medical Engineering & Physics, Vol. 29, 2007, pp. 930–934. B. Kemp, A., J. Janssen, and B. van der Kamp, “Body Position Can Be Monitored in 3D Using Miniature Accelerometers and Earth-Magnetic Field Sensors,” Electroencephalography and Clinical Neurophysiology, Vol. 109, 1998, pp. 484–488. Luinge, H. J., P. H. Veltink, and C. T. M. Baten, “Ambulatory Measurement of Arm Orientation,” Journal of Biomechanics, Vol. 40, 2007, pp. 78–85. Lyons, G. M., K. M. Culhane, and D. Hilton, et al., “A Description of an Accelerometer-Based Mobility Monitoring Technique,” Medical Engineering & Physics, Vol. 27, 2005, pp. 497–504. Lyons,G. M., G. E. Leane, and M. Clarke-Moloney, et al., “An Investigation of the Effect of Electrode Size and Electrode Location on Comfort During Stimulation of the Gastrocnemius Muscle,” Medical Engineering & Physics, Vol. 26, 2004, pp. 873–878. Lyons, G. M., G. E. Leane, and P. A. Grace, “The Effect of Electrical Stimulation of the Calf Muscle and Compression Stocking on Venous Blood Flow Velocity,” European Journal of Vascular and Endovascular Surgery, Vol. 23, 2002, pp. 564–566. Mansfield, A., and G. M. Lyons, “The Use of Accelerometry to Detect Heel Contact Events for Use as a Sensor in FES Assisted Walking,” Medical Engineering & Physics, Vol. 25, 2003, pp. 879–885. Mayagoitia, R. E., A. V. Nene, and P. H. Veltink, “Accelerometer and Rate Gyroscope Measurement of Kinematics: An Inexpensive Alternative to Optical Motion Analysis Systems,” Journal of Biomechanics, Vol. 35, 2002, pp. 537–542. Ni Scanaill, C., B. Ahearne, and G. M. Lyons, “Long-Term Telemonitoring of Mobility Trends of Elderly People Using SMS Messaging,” IEEE Transactions on Information Technology in Biomedicine, Vol. 10, 2006, pp. 412–413. Ni Scanaill, C., S. Carew, and P. Barralon, et al., “A Review of Approaches to Mobility Telemonitoring of the Elderly in Their Living Environment,” Annals of Biomedical Engineering, Vol. 34, 2006, pp. 547–563. Noury, N., G. Virone, and P. Barralon, et al., “New Trends in Health Smart Homes,” Proceedings of 5th International Workshop on Enterprise Networking and Computing in Healthcare Industry, Healthcom 2003, 2003, pp. 118–127. O’Donovan, K. J., T. Bajd, and P. A. Grace, et al., “Preliminary Evaluation of Recommended Airline Exercises for Optimal Calf Muscle Pump Activity,” EJVES Extra, Vol. 12, 2006, pp. 1–5. O’Donovan, K. J., D. T. O’Keeffe, and P. A. Grace, et al., “Accelerometer Based Calf Muscle Pump Activity Monitoring,” Medical Engineering & Physics, Vol. 27, 2005, pp. 717–722. O’Dwyer, S. B., D. T. O’Keeffe, and S. Coote, et al., “An Electrode Configuration Technique Using an Electrode Matrix Arrangement for FES-Based Upper Arm Rehabilitation Systems,” Medical Engineering & Physics, Vol. 28, 2006, pp. 166–176.

7.11 Conclusion

149

[27] O’Keeffe, D. T., A. E. Donnelly, and G. M. Lyons, “The Development of a Potential Optimized Stimulation Intensity Envelope for Drop Foot Applications,” IEEE Transactions on Neural Systems and Rehabilitation Engineering, Vol. 11, 2003, pp. 249–256. [28] O’Keeffe, D. T., G. M. Lyons, and A. E. Donnelly, et al., “Stimulus Artifact Removal Using a Software-Based Two-Stage Peak Detection Algorithm,” Journal of Neuroscience Methods, Vol. 109, 2001, pp. 137–145. [29] Pappas, I. P. I., T. Keller, and S. Mangold, et al., “A Reliable Gyroscope-Based Gait-Phase Detection Sensor Embedded in a Shoe Insole,” Sensors Journal, Vol. 4, 2004, pp. 268–274. [30] Roetenberg, D., H. J. Luinge, and C. T. M. Baten, et al., “Compensation of Magnetic Disturbances Improves Inertial and Magnetic Sensing of Human Body Segment Orientation,” IEEE Transactions on Neural Systems and Rehabilitation Engineering, Vol. 13, 2005, pp. 395–405. [31] Salarian, A., H. Russmann, and F. J. G. Vingerhoets, et al., “Gait Assessment in Parkinson’s Disease: Toward an Ambulatory System for Long-Term Monitoring,” IEEE Transactions on Bio-Medical Engineering, Vol. 51, 2004, pp. 1434–1443. [32] Shahid, S., J. Walker, and G. M. Lyons, et al., “Application of Higher Order Statistics Techniques to EMG Signals to Characterize the Motor Unit Action Potential,” IEEE Transactions on Bio-Medical Engineering, Vol. 52, 2005, pp. 1195–1209. [33] Veltink, P. H., P. Slycke, and J. Hemssems, et al., “Three Dimensional Inertial Sensing of Foot Movements for Automatic Tuning of a Two-Channel Implantable Drop-Foot Stimulator,” Medical Engineering & Physics, Vol. 25, 2003, pp. 21–28. [34] Wassink,R. G. V., C. T. M. Baten, and P. H. Veltink, et al., “Monitoring of Human Activities Using a Trainable System Based on Hidden Markov Modeling Technology,” Gait & Posture, Vol. 24, 2006, pp. S109–S110. [35] Williamson, R., and B. J. Andrews, “Sensor Systems for Lower Limb Functional Electrical Stimulation (FES) Control,” Medical Engineering & Physics, Vol. 22, 2000, pp. 313–325. [36] Williamson, R., and B. J. Andrews, “Detecting Absolute Human Knee Angle and Angular Velocity Using Accelerometers and Rate Gyroscopes,” Medical & Biological Engineering & Computing, Vol. 39, 202001, pp. 294–302.

CHAPTER 8

Contextual Awareness Medication Prompting Field Trials in Homes 8.1

Introduction This chapter presents the second of three case studies, where the methodology and techniques described in this book were used and refined in the field. The previous chapter emphasized technology selection and engineering issues; in this case study we focus on the requirements capture process, data analysis, and inference; we also consider a novel way to achieve location tracking using a single radio connection.

8.2

Problem Statement Adherence to a medication regimen is difficult for many people, and comprises a problem that pervades the health care industry [45]. In the United States, 125,000 deaths per year are attributed to nonadherence (two times that of car accidents) [29]. Lack of adherence leads to an overall cost of $15.2 billion to the healthcare system [44]. The five most common reasons for missing medications (nonage-specific) include [38]: • • • • •

Not having the prescription filled; Taking too much or too little medication; Taking medication at the wrong time; Forgetting doses; Stopping medication too soon.

Adherence is also affected by a complex set of lifestyle issues. Among the common reasons listed for general noncompliance are memory issues, socioeconomic status, age, belief systems, and patient education [29]. Adherence is a particular problem for older adults. Thirty percent of hospital admissions for seniors over 65, and 40% of nursing home admissions are due to noncompliance [30]. Compliance is believed to become more difficult with age due to the high number of medications taken by seniors and an increase in memory problems. Of those aged 65 and over, 75% of the population take at least one prescription medication, with most taking an average of 2 to 4 per day [47] Higher fre-

151

152

Contextual Awareness Medication Prompting Field Trials in Homes

quencies of doses, above two times a day, lead to exponentially increase in adherence problems [34]. 8.2.1

Medication Reminders

Although there have been many intervention studies of medication adherence (see [39] for a review), very few studies have successfully and systematically investigated automatic reminding systems. Cited studies largely focus on reminders such as human intervention (i.e., daily phone calls), special daily dose packaging, or family therapy. There has been little published work on designing a useful and usable automatic medication reminder that will be accepted and used by the older population. A few studies have focused on patients with HIV. Like many elders, these patients often deal with memory loss and with multiple medications to be taken at varying intervals throughout the day. Studies have shown that reminder interventions can indeed be successful in improving HIV patient adherence [46, 48]. In a recent study of 58 HIV patients, half were give a reminder device and half received only counseling. Those with the reminder took their medication 80% of the time, while those without did so only 65% of the time [31]. Tan and Chen [49] have described a study that tested an audio reminder with seven subjects, and they found that adherence increased with the reminder. In the study they described, they used an audio beep and a verbal prompt, but did not report any differences between the two in efficacy or preference. Nugent et al. [44] have described a system that reminds patients and also facilitates the prescription filling process and informs other stakeholders such as family and caregivers. The results from a study of three patients have been promising, but it is not clear at this point which aspects of the reminding system were effective and which were not, nor in which circumstances the reminder system failed. In both of these studies, a single type of nonportable audio reminder was tested.

8.3

Research Objective The objective of the project was to identify, implement, and validate an effective system for reminding older persons to take their medication. The system would need to take into account the context in which any reminding took place—the location, the activity of the older person, ease of access to the medication, distractions, and other issues—in order to be as effective as possible. To achieve this objective, the following research tasks were planned: 1.

2.

The first step was to understand why older persons forget to take medication. Once the underlying reasons for noncompliance with the medication regimen are clear, steps can be taken to address them. This involved ethnographic research in the homes of older people. The second step was to look at existing reminder systems and to discover which aspects of these reminders were effective and/or popular with older people, so that any new technology intervention could build on the state of the art. This involved a probe study of available technologies.

8.4 Ethnographic Research on Medication Routines

3. 4.

8.4

153

The third step was to engage in a participatory design exercise, where subjects designed models of their own “ideal” reminder technologies. The fourth step was to design and build a prototype solution that combined the best characteristics of the current state of the art with the new capabilities offered by wireless sensor networks and machine learning. This involved specification, technology selection, build, and test.

Ethnographic Research on Medication Routines Our focus on adherence grew out of extensive ethnographic research on elders, particularly elders with cognitive decline. In many interviews with older adults struggling to remain independent, we heard over and again how taking medications was a daunting task for the elder. Although it has long been recognized by the medical profession that taking medications is a key marker of the ability to live independently [41], hearing the same from many informal interviews emphasized the critical importance of this activity. The ability to manage one’s medications is clearly a sign of competence and independence for many older adults. The original ethnographic research focused on several broad issues of quality of life in older adults that have been reported elsewhere [42, 43]. For the current study, we reviewed the specific information gathered on medication adherence by reanalyzing the videotaped interviews of 17 elders across the United States. In addition, we conducted additional interviews with four elders and their family caregivers, focusing on the morning routines of waking, getting breakfast, and taking medications, and on the environmental aspects inherent to performing these routines. For older adults, taking medications was viewed as a critical part of their morning routine, and was often linked to other events to reduce the chance that they would forget. For example, many reported that they took their medications with breakfast, regardless of what time they had breakfast, or whether breakfast on any particular morning preceded or following their morning shower. Medications tended to be placed in locations where they would be noticed and where they were convenient. Thus, eye drops would be placed by the bedside so that patients could take them when they first woke up and were already lying down. Older adults often had elaborate organization schemes for their medications. In Figure 8.1, a person is showing how he turns his medicine bottles upside down after taking the first dose, then right side up after the second dose, and so forth. Given that he takes different prescriptions at different times of the day, he has memorized the different arrangements of right-side up and upside down bottles to determine if he is on track for that day. Additionally, nearly all older adults took nonprescription pills as part of their daily medication regimen. Although these were not seen as critical to take, they nevertheless tended to take them with their medications to ensure that they did not forget. This often resulted in them taking six or more pills at a time. Many set out their pills on a countertop or in a bowl and took them one at a time over the course of their daily activities.

154

Contextual Awareness Medication Prompting Field Trials in Homes

Figure 8.1

A participant shows how he remembers his medication regimen.

For the family members and caregivers of the older adults, taking medications was often a “signature event” that indicated whether someone was having a good day or not. As one care giver said, “Getting him to take his meds is a big deal, I would call every morning from work to remind him, he would say he had, and when I would get there in the afternoon, he had not taken them.” Thus, the ethnographic studies showed that: •

•

•

Adherence is a major concern among older adults and family. Nearly everyone reported problems in remembering to take their medications and supplements. In spite of the problems, few used reminding systems. Rather, they arranged their home environment and the placement of medications to facilitate access and provide informal memory prompts. Older adults generally link their medication taking to other contextual activities rather than time. This is more effective in helping them to remember, and provides more flexibility in their routines. However, it also can cause elders to forget their medications if their normal routine is disrupted.

The research indicated that a reminder device would solve a major problem for older adults, but that the device would need to be much more than an alarm clock. The device would need to be pervasive, located in multiple places around the house (where their medications were distributed), and would need to be context-aware rather than simply time-based.

8.5

Probe Study: Three Existing Medication Reminders Having completed the ethnographic research, the next step was to look at existing medication reminder systems. The aim here was to have older people use a range of systems available on the open market, and to find out what aspects of each system

8.5 Probe Study: Three Existing Medication Reminders

155

worked best for the subjects. This would then give the team information about the characteristics of a better medication reminder system. Three commercially available medicine reminders were purchased, that (between the three) exhibited a range of the variables we wanted to explore. These three are described below Visual-Pervasive

The visual-pervasive reminder (shown in Figure 8.2) is a simple battery-operated device that can be placed anywhere in the home. It has a red light that flashes at the medication time. The light continues to flash until the user presses a button on the device. This device has a magnet on the back for placement on a refrigerator or other metal surface. It is small and inexpensive enough that several of these devices can be placed around the house. Auditory-Portable

The auditory-portable reminder (shown in Figure 8.3) looks like a small alarm clock. The user can set up to four medication times a day. When the alarm goes off, a prerecorded voice says, “Time to take your pill.” The alarm will repeat every minute for 3 minutes, or will turn off if the user presses a button. The reminder is small enough to fit into a purse or a pants pocket, although it might be awkward in a shirt pocket. Text-Wearable

The text-wearable reminder (shown in Figure 8.3) is a watch that can display a message that is entered into a calendar-type of program on a computer. The message can be up to 39 characters in length. At the appropriate time, the watch emits a very

Figure 8.2 The visual-pervasive reminder is intended to be distributed around the house in easily viewed locations.

156

Contextual Awareness Medication Prompting Field Trials in Homes

Figure 8.3

The auditory-portable reminder and the text-wearable reminder.

faint beep and replaces the digital time display with the text message. The message will disappear after 1 hour, or when the user presses a button on the watch. Table 8.1 describes the characteristics of these commercially available products. With these three devices, we conducted a probe study to assess the relative merits on the different features. This approach is similar to the technology probes approach used by Hutchinson et al. [40], where technology is placed into home environments to discover usages and to aid in the codesign process. 8.5.1

Probe Study Participants

Ten older adults from the westside community of the greater Portland, Oregon, area participated. Table 8.2 shows the demographic breakdown of the participants. All participants reported that they were healthy, and they had a range of computer experience. Eight of the ten participants were retired, one worked part time and the other full time. All had normal or corrected-to-normal vision and hearing. All were taking at least two prescription drugs and at least one supplement daily. All participants reported that they had at least occasional problems in remembering to take their medications, but no one reported experiencing serious challenges in taking their medication. 8.5.2

Probe Study Procedure

One aspect of this study that was particularly challenging is that conducting testing in this domain poses some health risk. We did not want to disrupt an older adults’

Table 8.1

Reminder Characteristics Use

Reminder Form

Repeat Mode

Visual-pervasive

Blinking light

Keeps blinking until but- Place in key areas around ton the house is pressed

Audio-portable

Voice: “Time to take your pill”

Repeats every minute for Place in a single area, can 3 minutes then stops take it with you

Text-wearable

Text message

Displayed for 1 hour, or until user dismisses it

Wear continually, must charge at night

8.5 Probe Study: Three Existing Medication Reminders Table 8.2

157

Participant Demographics (Ranges in Parentheses)

Male/Female

Average Age

Average Number of Medications

Average Number of Supplements

Single/Spouse

3/7

73.3 (65–85)

3.7 (2–7)

4.1 (1–7)

4/6

medication regimen or endanger their health in any way. Therefore, instead of using the reminders to take their own medications, we developed a proxy task in which participants were asked to use a reminder to take a breath mint twice a day for 2 to 3 weeks. We instructed them to maintain their medication regimen as they normally do, and not to try to use the reminders for their own medications. We felt that this was an acceptable risk trade-off. Participants would still be performing an activity very similar to taking medications, but there would be minimal risk should the procedure result in nonadherence. The procedure consisted of an initial interview followed by four periods during each of which participants tried one of four different reminding conditions. Each period lasted between 3 and 8 days. Thus, all participants experienced all four reminding conditions. Participants kept a journal in which they recorded the times they took their dose, and the conditions under which they remembered (or did not remember) to take it. At the end of the fourth reminding condition, we interviewed participants about their experiences and their opinions of the different reminders they tried. We also conducted a participatory design exercise in which they created their “ideal” medication reminder. In the initial interview, we asked participants about their current practices of taking their medications, and how often they forgot to take their meds. We asked them to show us where they stored their medications, where they actually took their medications, and to show us any heuristics or methods they use to remember to take their meds. The session was audiotaped, and we took photos of their medication bottles, the locations in the house where they took their medications, and any devices they used to remember to take their medications. Each participant received the four med reminder conditions in a randomized order. In the no reminder condition, participants were asked to simply try to remember to take their mint as closely as possible to a specific 12-hour interval (for most participants, this was 9 a.m. and 9 p.m.). If they had not taken the mint within 1 hour of the required time, they were to skip the dose. Participants were asked to record the time that they took the mint, and to record how they remembered to take the mint. If they missed a dose, they were to record the reasons why they had missed it. Participants used a seven-day pillbox for all conditions. In the three reminding conditions, participants were asked to use one of the three reminders: the visual-pervasive, the auditory-portable, or the text-wearable reminder. Participants were asked to keep the same routine as in the no reminder condition described above. Each time participants switched to a new condition, the experimenters brought the new reminder to their house, set it up, showed them how it worked, counted the pills to validate their diary entries on adherence, and refilled the medicine box. In the final interview, we first reviewed the participants’ journals and verified that all entries were completed, and clarified any entries that were not clear. We

158

Contextual Awareness Medication Prompting Field Trials in Homes

then asked them which device they preferred and why, and asked them to describe how they used the devices. Participants also filled in a short questionnaire, rating the devices. Data was analyzed in a number of ways. We reviewed the videotapes to pull out the most interesting and informative stories and cases. The journals provided detailed data on when participants failed to take their pill, and the design exercise provided physical models of preferred designs. 8.5.3

Probe Study Results and Discussion

Table 8.3 shows the incidence of nonadherence. Participants had a 96% adherence rate, forgetting to take their medications 25 times out of a possible 388 occasions. This is a higher figure than is generally reported. Typical studies show adherence to range from 50% to 80% [32, 33]. However, this is not surprising given the fact that participants were asked to write each dose event in their journal and that in three of the four conditions participants used a medication reminder. In fact, the no reminding condition showed a nonadherence rate that is more in line with the literature. It is clear that the auditory-portable reminder worked most effectively. The reasons for its high rate of effectiveness are discussed below. The journals were analyzed to understand the context and proximate reasons why the dose was not taken. Table 8.4 shows a breakdown of the reasons given for not taking their dose and their location at the time when they were supposed to take it. As the table shows, when participants were away from home, the reasons for not taking their dose were different than when they were at home. Participants either didn’t have their meds, didn’t have their reminder, or couldn’t hear their reminder when it went off. At home, on the other hand, participants often reported that unusual events caused them to miss their doses, such as when they had company, had to leave in a hurry, or slept in. For all journal entries, participants were asked to write down whether the dosage event was a normal event or a nonroutine event. Table 8.5 shows a breakdown of “no, not normal,” “yes, normal” or “no” response. Participants forget during a nonnormal event by a 2 to 1 margin. By comparison, when users remembered their dose, the ratio of nonnormal to normal events was 1 to 4. 8.5.4

Device Preferences

Participants were asked to rate the devices in order of preference. The visual-pervasive reminder was rated the least preferred, as many participants failed to see the flashing light. Participants also complained about its lack of portability. Although it

Table 8.3

Adherence in the Four Reminding Conditions

Reminder Condition

Missed Doses

Total Doses

Percentage Missed

None

9

96

9.3%

Visual-pervasive

7

92

7.6%

Auditory-portable

1

97

1%

Text-wearable

8

103

7.8%

8.5 Probe Study: Three Existing Medication Reminders Table 8.4

159

Reasons for Forgetting the Dose by Location Location

Reason

Away

Away from home—no meds

4

Didn’t have reminder

2

Didn’t hear reminder

2

Home

Yard

Total 4

1

1

4 2

Didn’t see reminder

3

1

4

Forgot

2

2

Had company

3

3

Left in a hurry

1

1

Not feeling well

1

1

Watching TV

1

1

3

Slept in 8

Total

Table 8.5

3

15

2

25

Normal Versus Nonnormal Routines in Missed Dosage Events Normal Routine?

Reason

no

Away from home—no meds

2

Didn’t have reminder

1

Didn’t hear reminder Didn’t see reminder

1

yes

N/A

Grand Total

2

4

3

4

1

1

2

1

2

4

2

Forgot

2

Had company

3

3

Left in a hurry

1

1

Not feeling well

1

1 1

Watching TV Slept in

2

Grand total

11

5

1 1

3

9

25

was possible to take the device outside of the home, the lack of audio rendered it impractical to keep in a purse or pocket. The auditory-portable and the text-wearable were rated about the same, yet it was clear in talking to participants that they felt the auditory-portable was the most effective. The text-wearable seemed to be rated highly more for its potential than for its actual functionality, as participants complained about its bulk, its appearance, the inaudible beeper, and the difficulty of putting it on and taking it off (the watchband on this device was very difficult to use). In the auditory-portable device, par-

160

Contextual Awareness Medication Prompting Field Trials in Homes

ticipants liked its clear audio signal, and many liked the recorded voice that said, “Time to take your pill.” Participants also liked the fact that this device repeated its message three times. It should be kept in mind that although the adherence rate was very high for the auditory-portable device, we would not expect adherence to be this high in the older population. Unlike what we would expect from the typical elder who needs a reminding device, our participants were highly motivated and reported no memory problems. Furthermore, the journal activity and the frequent visits by the experimenters kept the dosage task very high in their mind. Furthermore, none of the participants felt this was the “ideal” reminder, and all had ideas for improvements. This led into the next research step—a participatory design exercise that helped participants more clearly articulate these improved features and helped combine them into a single concept.

8.6

Collaborative Design Great discoveries and improvements invariably involve the cooperation of many minds! —Alexander Graham Bell

After having the opportunity to use each type of reminder in the home for a period of days, users were queried on what the ideal reminder might be for their particular needs. To best understand the ideal reminder, a participatory design exercise was added to the exit interview. Historically, participatory design has been used when planning community or living space. Institutions such as Umpqua Bank have used similar methods when redesigning their space to fit user needs [36]. This is largely due to architects’ and community planners’ desire for input from the people who will be residing in these spaces. More recently, industrial designers have begun to implement similar processes to better understand user needs for a wide variety of consumer products. Demirbilek et al. [35] ran a participatory design session in Turkey with adults aged 65 and over to better understand their desires for the doors and door handles of the house in which they would want to age. Small groups (3–6 people) took part in these sessions. Designers in this experiment used interviews, scenarios, and sketches from designers and then encouraged discussion and sketching from the participants. Participatory design was also used effectively in a study regarding an orientation aid for amnesiacs [50]. Six users were involved in a study using a PDA to assist in orienting individuals with memory loss. By having actual amnesiacs use the product in everyday situations, designers were able to learn more from the user’s perspective and also better understand real-life issues from the point of view of each user. In this project, participants were given a lump of Play-doh, wooden buttons of various sizes, foam that is flexible and cuts easily, and some string. Play-doh was chosen specifically because it is easy to manipulate and has an inherent “fun” factor that often reduces people’s fear of “not being a great artist” when asked to create

8.6 Collaborative Design

161

things in clay. We asked participants to design their ideal reminder device, and asked them to describe what they were creating and how it would work. Nine out of ten participants designed a wearable device. One device in particular was clearly designed as a versatile device with options to wear it as a watch or as a pendant (Figure 8.4) Those who designed a necklace form often expressed a desire to be able to hide it under a shirt. The one user who did not design a wearable reminder created a product that combined the visual-pervasive and the auditory-portable. This device would be round and have a digital face, stand on a tabletop and make a beeping noise until it was turned off. All users designed objects that had an auditory reminder. These reminders ranged from beeps to bird noises and several referenced the electronic voice they heard on the auditory-portable device. The concept of an alert that would continue for 6 to 20 seconds or one that might repeat was also frequently requested. One participant desired vibration as an alert due to the time he spends driving in a loud truck where he may not hear an alert. Many opted for a digital face over an analog one as they are easier to see. Opting for simplicity, users generally designed objects with minimal buttons. Given that the majority of the reminders were wearable, it is also interesting to look at the average size of the desired watch or locket. The men designed larger, and, more importantly, thicker reminders. The average for men was 9.5 mm thick whereas the women’s reminders averaged 5.5 mm. The width and length of the face for the wearable designs range from 25 to 45 mm for women and 36 to 53 mm for men, with most of the women’s falling in the middle range around 36 mm. The shapes were all round or oval. The thicknesses had a variation of 3 to 8 mm for the females and 9 and 10 mm for the males. Not surprisingly, women designed smaller, thinner faces and men designed larger, thicker ones. By working through this participatory design exercise, it became quickly apparent that several features are desirable across the user spectrum. According to this exercise, the ideal reminder is a new combination: wearable-audio. The reminder has a noise of some kind to alert the user it is time to take their medication, a digital display, and only the most necessary buttons. Physically, the reminder is smaller for

Figure 8.4 User’s rendition of a wearable concept. It is intended to double as both a watch and as a pendant.

162

Contextual Awareness Medication Prompting Field Trials in Homes

women than for men, and allows the user the flexibility to wear it as a pendant or a watch.

8.7

Ethnographic, Probe Study, and Collaborative Design Results The ethnographic work combined with the probe study and the participatory design exercise revealed the following requirements: •

•

•

•

•

•

A reminder should be context-aware; that is, it should know whether the user is at home, away, has company, or is about to leave. The reminder should avoid false alarms by knowing if the user has already taken his or her medications. Users prefer to take their medications based on routines and contexts, not time of day. The reminder should time reminders to occur when the user is performing supporting routines, such as mealtimes. The reminder should be primarily audio-based, with visual only for occasions when the reminder is very likely to be seen. For some individuals with hearing problems, of course, visual will be preferred, so this should be configurable. The reminder should be portable and easily worn. A watch form factor provides a very unobtrusive and appealing reminder, since it provides the additional functionality of telling the time. A necklace form factor should also be available. However, the reminder should be augmented with more pervasive reminders in the home for occasions when the reminder is not worn (e.g., when a dose might be missed due to sleeping in).

Given these requirements, the next step in this exploration of medication adherence is to develop a system that is aware of the users’ activity and location to more appropriately prompt them when they are in the vicinity of the medication.

8.8

Use Cases Use cases describe scenarios where the solution is used by the subject, and describe the behavior of the system in response to subject input or activity. The following use cases were outlined to describe the activity of the solution in the field. 8.8.1

Use Case #1

It is five minutes past the time to take the medication, and the patterns of activity do not indicate that Martha is about to take her medication. Martha is currently in the bedroom, so the system activates the activity beacon in the bedroom, and the spot watch. The activity beacon starts flashing, and the watch begins to beep. When Martha presses either the red button on the activity beacon or the button on her watch, the reminders stop for five minutes. If the iMed Tracker is not opened in that time, the reminders resume, depending on where Martha is located. (Note: system

8.9 Technical Design

163

records which button was pressed and the time, so that we can assess the effectiveness of the reminding device, and where it was received.) 8.8.2

Use Case #2

It is Tuesday, and Sam normally leaves home early to go to his church volunteer group meeting. The system has learned this pattern from the baseline data collection period, and it knows that Sam often forgets to take his medication on these days. The system senses that Sam has risen at his normal Tuesday time (which is earlier than other days), and ascertains that he is likely to leave early. As Sam prepares to leave, the system sends a signal to his watch, which begins beeping and displays a message reminding him to take his medication with him. Then, at the appropriate time while he is away from his house, his watch begins beeping and reminds him to take his medication now. He presses the button on his watch to indicate that he has taken it. After he returns home, the watch sends this data to the CAMP system confirming that he has taken his medication. 8.8.3

Use Case #3

Normally, Sally takes her medication at 8:30 a.m. It is 8:35 a.m., and she has not yet opened the iMedTracker. However, the system detects that Sally is still in bed, and the lack of movement indicates that she is still likely to be sleeping. Therefore, the system waits until 9:20 a.m. until it prompts. This allows Sally to sleep a while longer, but still gives an opportunity to take her medication within the 1-hour time frame. Because she is not likely to be wearing her watch in bed, the activity beacon on her nightstand begins to flash and beep. Sally can turn it off by pressing the button if she chooses to continue sleeping.

8.9

Technical Design The results of the ethnography and probe study provided key user inputs to the requirements specification for an improved context-aware medication prompting solution. Such a solution needs: • •

• •

8.10

A wearable audio reminder; Awareness as to whether or not medication has been taken, through the use of a “smart pillbox”; Environmental (motion, bed, door, phone) sensors; Software intelligence to “understand” the location and activity of the subject, and to trigger reminders in a context-sensitive manner.

Technology Selection The system consists of the following key elements (see Figure 8.5):

164

Contextual Awareness Medication Prompting Field Trials in Homes X10 door/light/motion BBV3 iMed tracker Kitchen

Dining Entry Health SPOT for location/prompting X10 motion/light

Bathroom Bedroom Living area

Tactex bed sensor Figure 8.5

1. 2. 3. 4. 5. 6. 7. 8.

Layout of sensors in home.

The iMedTracker, smart pillbox; Reminder watch called the Health SPOT watch; Up to three activity beacons; Phone sensor; Bed sensor; Motion/light sensors (one per room plus one outside front door); Door switch sensors (front door and refrigerator door); The system software, running on the home server, which analyses and infers the correct action to be taken by the system.

The iMedTracker (Figure 8.6), a pillbox designed to mimic a traditional pillbox, houses a smart system and logs data when the doors to the pillbox are opened. Logging is done through sensors in the lid. When the door to a compartment is opened, the pin sensor is released, and when the door is closed, the pin sensor is depressed. This action logs the data that a pill has been taken. If the iMedTracker is not opened in a reasonable amount of time around the medication schedule, the device can light up the door of a particular compartment alerting the user that it’s time for medication. If the medication is still not taken a signal can be sent to one of several other smart devices in the home. The Health SPOT (Figure 8.7) is a modified version of the wearable-text device. As a result of the participatory design, it will be changed. Portability was mentioned by many users to be a significant design feature. As suggested by users, the watch will be adapted so that it may also be worn as a necklace or pocket watch. User feedback on the Health SPOT also suggests that the tone needs to be louder and continuous. Due to technical constraints, the team is unable to make the beep louder; however, the Health SPOT will have a recurring alarm tone coupled with the visual

8.10 Technology Selection

Figure 8.6

The iMedTracker.

Figure 8.7

The Health SPOT watch.

165

text prompt. In addition, the watch will have location abilities, so that the reminder system knows if the user is at home or away, and can modify its prompting strategy accordingly. The activity beacon (Figure 8.8) came out of the original ethnographic research, and is designed to support daily activities. In the current context, it is used as an environmentally placed reminder to assist in prompting. If the user is in the home and has not responded to the prompt on the watch, an activity beacon may begin to blink its three LED lights. With the final option of a voice prompt, the activity beacon may send out a more audible beep or buzz or it may send out a verbal message such as, “Mom, don’t forget to take your heart pills.” By adding a voice, a caregiver can gently remind a senior not only to take a pill, but also what the pill is for if the senior is experiencing confusion or cognitive decline.

166

Contextual Awareness Medication Prompting Field Trials in Homes

Figure 8.8

Activity beacon.

The system software runs on a home server, a dedicated laptop machine with an attached radio base station. The system software collects and analyses all sensor data, and uses an inference engine to identify appropriate opportunities to remind the subject to take medication. The phone sensor notes when the phone rings, when it is answered, and when it is hung up (i.e., the duration of the call). The fact that the subject is on the phone may indicate that this is not a good time to remind her to take medication. The bed sensor notes when the bed is occupied, and the subject presumably asleep. During this time, the system may opt not to remind the user, or to delay any prompting for a period after the set reminder time, in order not to disturb sleep. The motion sensors detect the presence of the subject in the home, as well as the room where the subject is. This informs the prompting decision—prompting when the subject is physically close to the pillbox is likely to be more acceptable and more successful. When the subject is out of the house, prompting may be suspended, or may use some alternative channel. Motion sensors can also serve to identify the presence of more than one person in the house (i.e., a visitor). The door sensors are placed on the front door and on the refrigerator door. The front door sensor data can be used to infer information about the presence of the subject; it can also be useful in detecting the presence of visitors. The fridge door sensor can provide information about the preparation of food. Each of these technology elements is explored in some detail in Table 8.6.

8.11

Prototype Definition Requirements Document A simplified prototype definition requirements document (PDRD) for the solution is given here. 8.11.1 8.11.1.1

System Description: iMedTracker Enclosure Description

Requirements

The enclosure is based on a survey of existing systems in the marketplace that are not sensor enabled. The device must contain seven cells (chambers that hold medi-

8.11 Prototype Definition Requirements Document Table 8.6

167

Technology Features

Feature

Purpose

Key Requirements

iMedTracker

Store medication. Track taking of medi- Informs system of door opening and cation. closing Alerts by lighting up relevant door for medication to be taken

Health SPOT watch

Prompt subject to take medication. Be aware of subject location.

Watch form factor Audio prompt Text prompt on watch face Wireless transmission of data Rechargeable batteries

Activity beacon

Prompt subject to take medication.

Audio prompt Visual prompt

Phone sensor

Identify when subject is on the phone.

Informs system of phone use

Door sensors

Identify when front door and refrigerator door are opened and closed.

Inform system of doors opening and closing

Motion sensors

Identify when subject (or other person) is in the room. Note motion (or lack thereof).

Inform system of movement in the room

Bed sensor

Identify when subject is in bed.

Inform system of presence in bed

Software

Infer context.

Data acquisition from sensors Data processing and inference Data storage and retrieval

cation tablets). Each cell must have a door that locks and is also easily opened by an elder, yet can withstand a 5-foot drop without the door opening. The cell internal dimensions shall be no less than 1.25 inches in width, 1.0 inch in depth, with a 2.0-inch door opening as measured from the pivot point of the hinge. The bottom of the cell wall will be parallel to the lid when closed for no less than 1.0 inch with an arching radius of no more than 0.4 inch from the bottom of the cell to the front of the cell where the lid meets the front wall. One must be able to distinguish an LED illuminated cell from a nonilluminated one through the lid of the cell. Likewise the sides of the cell must not allow light to transmit from one cell to another, other than through the lid. Figure 8.9 shows a schematic of the cross section of the cell. The enclosure must have room to support an LCD 2×40 characters, two LiPolymer batteries, two LEDs visible to the outside, and two buttons of different color 0.5 inch in diameter. The enclosure must also have room for the radio, main sensing board, and switches to detect the doors of the cell being opened or closed. Each cell must be illuminated by an LED (blue) from the bottom of the base board. The illumination of the LED is driven by the embedded processor (see Figure 8.10). These LEDs may be used as a device to prompt the elder, depending on the outcome of probe studies conducted by the team.

168

Contextual Awareness Medication Prompting Field Trials in Homes

Table 8.7

iMed Tracker General Usage and Requirements

iMedTracker

Sensor to detect if the pill box was open; send a time stamp and the event when it occurred.

LED blue to light the pill cell RF transmission for the event Watch dog RTC and alarm feature LCD display 7 pill sections AC/DC options Internal memory in case patient is away must be sufficient for a weeks’ worth of data. Time stamp, event, prompt responses, prompt driven Two push button Buzzer nice to have) Two LEDs, green, red One LED may be used to drive a low battery One LED for prompting Each cell needs a method of detecting if open Radio and prompting only work on AC 1.2 pounds weight limit

Lid 2.0”

Front Wall

Rear 1.0” 1.0 1.0”

0.40R” Cross Section of the Cell Figure 8.9

Cell cross section.

The overall enclosure size must be no more than 10 inches long, 6 inches deep, and 2 inches thick. Design Choice

Figure 8.11 shows the enclosure. The two buttons on the left of the screen fill the requirements for yes and no queries on the LCD screen. The LCD screen is a 2-line by 40-character screen that can be backlit. Two LEDs, one red and one green, are on

8.11 Prototype Definition Requirements Document

169

LED Lighting the Cell

Figure 8.10

LED lighting.

Figure 8.11

Enclosure.

the right side of the LCD for debug purposes. Each cell is covered by a lid from an existing pill storage device and refitted to the iMedTracker. Board Description

The following is the design choice for the iMedTracker prototype. The device is based on a Bluetooth-enabled device created by Tamara Hayes at Oregon Health Science University. Here the device may be used either as a medication adherence detection device or as a medication prompting and reminding device when added into the CAMP hardware system. The device contains three boards: the base board, the LCD carrier board, and the Bluetooth module board. The base board is the only one that has not been designed in the system stack thus far. All other boards are currently commercial products. The board design is a four-layer 50-Ohm impedance controlled board with 8-mm trace and space. Test points for all nets are located on the back of the board.

170

Contextual Awareness Medication Prompting Field Trials in Homes

8.11.1.2

Embedded Processor

Design Choice

The embedded processor on the iMedTracker is an Atmel ATMEGA 128L. This is a 3.3V-part running at 8 MHz on the main board of the design. The processor is programmed through the ICP port on the board located at the far right side of the board with the top side up. The processor’s JTAG port is located on that side as well. 8.11.1.3

Radio

Requirements

The sensor network systems must be capable of transmissions and reception near the human body without human body interference. In order for them to function as wearable sensors in the home and hospital they must be less than the following: (<weight requirement 3.5 oz / 90 grams = battery (1.4 oz), radio, plastics (1.2 oz), sensor board). The radio in the sensor system must support two-way communication (sensor→base, base→actuator). System range to cover a house (home size depends on business model): •

•

• •

•

Must cover via a multihop protocol but must not significantly impact battery life; Must be able to have the base station at one side of house, and the most distant sensor/actuator at other side, roughly 30 feet; Must be able to penetrate multiple floors; Issues of apartments, construction materials, bodies in line-of-sight must all be evaluated; Must be primarily battery-operated but tolerates wall-powered.

Note: Previous measure of goodness boils down to (for motes): 30 feet + 3 walls + 1 human. Since the industrial, scientific, and medical (ISM) band is used for a variety of communications systems, the sensor network must support multiple networks (commercial, low-functionality sensors, such as RFX10 and research sensors such as motes). Further, the sensor network sensors must also coexist with other RF systems in the house, such as 802.11, wireless phones, and so forth. The embedded processing requirements should have a programming interface that is common to embedded programmers to enable the industry. This may include POSIX, Lunix, C++, 8051 assembly, or some other common standard. Since the sensors are running and may not be always streaming due to duty cycle requirements, the data and software must reside on the sensor. The sensor must wake on a trigger event from sleep and sleep in the sub-20 μW power range. The sensor system must wake and operation must be below 8 mA. To fit into most sensors, the embedded processor must have hardwired A/D ports and must have hardwired PWM ports. The system should have hardwired UART (2 UARTs is a soft requirement) to connect more than one embedded processor together.

8.11 Prototype Definition Requirements Document

171

Design Choice

Recommendation is to use the BlueRadios SC-BR30A (Figure 8.12). This is a Bluetooth radio that is a Class 1 device and is programmed and driven through the UART of the PIC embedded processor described above. Bluetooth Class 1 range is specified at 100m using an internal antenna mounted on the BR30A module. The device sends and receives commands using a series of Hayes Modem commands. The iMedTracker will signal the BlueRadios USB communicator which is a Class 1 device, the same as the PC base station. The number of devices for the CAMP system is small so the device will be part of a piconet to the PC base station. The watchdog messages and prompting will not be driven when the device is not wall-powered. 8.11.1.4

RTC and Watch Dog

Requirements

A real-time clock with a nonvolatile memory and internal battery is needed for the design. The clock must be 2V to 7V-tolerant and have support 5V-TTL level signals. Due to the size of the boards in other designs, a common clock across all the designs is necessary. Design Choice

Due to the cost and the size, the Dallas Semiconductor 1302 RTC was chosen for the design. The DS1302 supports the requirements for the design and comes in an 8-pin SOIC on 150-mm pitch that satisfies the requirements for the design.

Figure 8.12

BR-SC30A device.

172

Contextual Awareness Medication Prompting Field Trials in Homes

8.11.1.5

Matrix LCD

Requirements

In anticipation of using of a human readable output, a dot-matrix LCD is included in the design. The dot-matrix LCD must be at least a 12-point font as defined by usability guides for elders. This font size relates to a 3.5×5.2 mm character size. The device must be 3V- or 5V-tolerant and have a backlighting. Forty characters and two lines are required in the LCD. Design Choice

The CFAH2402A-YYB-JP from CrystalFontz America is the choice for the design. The CrystalFontz LCD is green backlit with a 24×2 character size (Figure 8.13). The main board of the system will have a 16-pin header that will connect to the LCD through a ribbon cable off the main board. The power enable on the battery-charging circuits will run the backlighting of the device, so when the device is plugged into power the backlight will be on. If the device is not plugged in, the LCD will not be powered to save on the battery life. 8.11.1.6 Sensors Requirements

In the iMedTracker the adherence of a medication regime is sensed through inferring the fact that a cell is opened on a Saturday through Sunday medication regime. Since there are 7 days in a week and the iMedTracker will have both a 7-day and 14-day regime, the requirement is for 14 switch sensors to detect the opening of the 14 cells. There will also be the need for two additional push-button switches for yes and no feedback from the LCD prompt. Design Choice

To satisfy the sensor requirement the iMedTracker will use 14 of the ITT K6 series tactile switches. These devices have embedded green LED that operate separately and can be used to illuminate the active cell for directing attention to the proper cell (Figure 8.14). These switches are mounted around the board and are activated when the door is open or closed. On the top of each cell nearly flush with the enclosure is a LED light pipe. This LED light pipe contacts the tactile switch and the inside of the cell door. This light pipe serves two proposes: first, it is the mechanical connection to the switch, and second, it acts as an optical conduit for the LED on the board (Figure 8.15).

Figure 8.13

LCD choice.

8.11 Prototype Definition Requirements Document

Figure 8.14

173

ITT K6 Series THM tactile switch.

Figure 8.15 Partial assembly of the system showing the K6 switches (antenna has been removed from the design).

A backing plate is required to strain compensate for the pin/switch pushing back on the board. This is shown in the assembly drawing (Figure 8.16). The two other switches for the yes and no buttons are the ITT K6 series switch without the LED embedded. The switches are multiplexed into the PIC with the LEDs as seen in the sample schematic in Figure 8.17. 8.11.1.7

Power Requirements Design

Requirements

Device will need to run 7 days outside the home without using wall power. While in the home the device should be plugged into the wall. Power will be supplied to all components while the device is wall-powered. When the device is not wall-powered, all sensor data will be stored in the EEPROMs on the device. Once the device is plugged back into the wall the Bluetooth radio will send the data to the PC. Data will not be lost while unplugged. LCD will not be enabled while batterypowered.

174

Contextual Awareness Medication Prompting Field Trials in Homes

Stiffener plate

Mainboard

Switch housing case

Plastic enclosure

Figure 8.16

Breakout of the enclosure, the K6 switch, and the stiffener plate.

Design Choice

The device will be powered by two Li-Polymer batteries connected to a BQ24010 Battery Monitor IC. This device receives its power through the wall-powered 5V-DC brick and tapped into the board using a K connector shown in Figure 8.18. Both a 3V- and 5V-linear voltage regulator is in line to power the various devices on the main board. The batteries are connected through a 2-pin header on the board that will not be stuffed, but the ends of the wires for the power and ground are soldered into these through hole mounts. 8.11.2 8.11.2.1

System Description: Health SPOT Purpose

The Health SPOT is a modification of the SPOT Watch (Figure 8.19) sold to support MSN Direct communication to SPOT devices. The research prototype in this program will be a commercially available watch with an incorporated Bluetooth module tied to the UART of the embedded processor in the device. The device will be used to track elders in their homes through RSSI on the Bluetooth modules (BT) in the Black Box Version 3 (BBV3). The modified watch will send out periodic beacons at a specified time and wait for an acknowledged received message from the contextual aware medication prompting (CAMP) system. The CAMP system will pick up the RSSI of the BT radio to determine the position of the elder in the home. If the elder leaves the home the modified watch will begin logging the various FM broadcast signal strengths. The embedded processor in the modified watch will average the various samples and include a time stamp for the average (Figure 8.20). These averages of 10 towers and time stamp for each location read will be stored in the memory on the memory of the embedded processor currently existing on the watch. Once the Health SPOT has received an ACK message again in the home,

Figure 8.17

Sample of the schematic for the switches and LEDs.

8.11 Prototype Definition Requirements Document 175

176

Contextual Awareness Medication Prompting Field Trials in Homes

Figure 8.18

K-connector for the 5V-brick.

Figure 8.19

Health SPOT watch.

then contents on the memory of the average RSSI numbers and times will be downloaded to the PC in the home. The watch will store up to 6 hours of RSSI data when the watch is outside the home. If the watch is outside the home beyond 6 hours, no more data will be collected from the FM towers. 8.11.2.2

Radio

Requirements

A simple Bluetooth radio must also be incorporated in the design that will communicate with the Health SPOT device. The Health SPOT device is described in the HealthSPOT PDRD and contains a Class 2 OEM Bluetooth Module: Promi-ESD-02 from Lemos International (http://www.lemosint.com/scripts/ bluetooth_promiesd_02.asp). Design Choice

To communicate with the Health SPOT device we use the BR-SC30N. This radio is a Class 1 tunable device that has the same SMA connector and a Gigant antenna as well. In this configuration the module speaks to the mote through the UART on the two devices.

8.11 Prototype Definition Requirements Document

Light

177

Prompt acknowledge or page up

Enter Channel/mode change button

Figure 8.20

8.11.2.3

Prompt denial or page down

Buttons on the watch.

Enclosure Description

Requirements

The enclosure for the Health SPOT is modified from the Suunto n3i SPOT watch. The back of the Suunto n3i will be modified to accommodate the additional daughterboard, battery, and functionality described in this document. The other form factor requirement is the device must be capable of fitting the power clamp shown in the power section in Figure 8.21. 8.11.2.4

Board Description: Power Requirements Design

Requirements

The Health SPOT device should be charged each night by the elder in the study. As such the elder may not charge the device in any given night. If the watch is not recharged it should last at least until the next night. Based on this usage the Health SPOT device should work for 48 hours without recharge. When the Health SPOT devices senses it is plugged into the wall or being powered for recharge the device will not connect to the BT network. The usage model should be that the elder is instructed to recharge at night while asleep. Hence bed sensing and X10 motion will be used at night to confirm the position of the elder. Design Choice

Similar to the functional SPOT Suunto n3i devices, the Health SPOT will recharge using the clamp device with four contacts (see Figure 8.21). 8.11.2.5

Embedded Software Description

Introduction

Included in this section is the description of the embedded code and algorithm on the Health SPOT device. There are two additional embedded features to the watch that are not on the standard SPOT watches on the market. The first is the location stack software and the second is the prompting stack software. The following two sections discuss the pseudocode and algorithms for both. The Health SPOT device is intended to communicate through the BBV3.

178

Contextual Awareness Medication Prompting Field Trials in Homes

Power brick

Recharging clamp

Figure 8.21

Charging the SPOT watch.

Location Stack Pseudocode

The location stack is broken into two segments. The first is the location in the home as detected by the RSSI or radio signal quality indicator through the Bluetooth module on the Health SPOT device. The RSSI or radio quality indicator is sensed from the reception of the BT signal on the BBV3. As the BBV3 is specified to be either a relay for BT and Telos or a base station device for the PC, the algorithm works the same in both instances. Figure 8.22 is a schematic of a floor plan for illustration. In the diagram the RSSI is indicated by the color intensity of the green background and the scales on the side are intended to represent the radio quality at the various levels working back from a base station in the upper left corner of the kitchen. In Figure 8.22, the white line running diagonally through the floor plan represents lines of iso-RSSI. From this the reader may believe that the RSSI may show that the watch may be in the bedroom, bathroom, or the dinning area without the ability to resolve the actual position of the device. In actuality this is idealized and not seen in most applications of RF technology. In most instances due to reflections, bounces, interference, and the inability of the RF to penetrate objects it may be much more complex. As such the X10 motion detectors will be used to pinpoint exact location. For example, if the RSSI on the Health SPOT indicates 70% and Dining_Motion is true, then there is a high probability the watch and wearer are located in the dining area. Once the device leaves the area of the apartment the Health SPOT will no longer receive an ACK from the BBV3. In this case the device will begin scanning the 10 FM towers in the area and logging the RSSI of the FM towers. In this case the device will read each tower’s RSSI 50 times and average them, and store the average before moving on to the next tower and repeating the process. This should continue until there are 10 averages from the FM towers in the area. Once this is completed the Health SPOT should attempt to reconnect to the BT network. If there is no ACK from the BBV3 the FM tower RSSI process should continue. Once the BBV3 and Health SPOT reconnect, the FM RSSI information should be downloaded to the PC via the BT network.

8.11 Prototype Definition Requirements Document 99%

78%

179 65%

54%

99%

84%

69%

44%

Figure 8.22

Lines of RSSI.

Location Stack Ping (consists of watch ser# and time), Wait TBD sec’s for reply If reply. Loop @ 30 sec interval No reply, Log FM RSSI DO FM TOWER(J) J=1,10 READ FM Tower(J) RSSI i=1,50 FM_TOWER_AVG(J) END DO Wait ~ 1 (TBD) min, then ping If reply, send RSSI Log No Reply, Loop @ 5 (TBD) min FM RSSI RSSI log message format: Time, Avg. RSSI, Tower ID, Watch Ser#, Sample# Continue to send until ACK’ed Max ACK time 30 sec. – 1 min (TBD)

All messages use ACK/NACK protocol between watch and base station. Prompting Stack Pseudocode

To understand if the prompts are useful and can be received, the Health SPOT will send prompts to the elder through the BT network. These prompts will be issued when the device is close to the iMedTracker and will be pushed forward on the display. The displays of the prompts will resemble the diagram shown in Figure 8.23 where the watch will ask the user to acknowledge the prompt. Once the prompt is acknowledged, that information will be forwarded in the BT network back to the PC.

180

Contextual Awareness Medication Prompting Field Trials in Homes

Have you taken your vitamins?

Figure 8.23

The watch display.

Prompt Stack Message from PC: “String”, Ser#, Time Sent Sent until ACK’ed Watch: Push Prompt to Front Prompt Display “String”, “Yes”, ”No” Wait for a Response Watch Response: Prompt Status, Time of Prompt Button Pressed, Ser#

8.11.3 8.11.3.1

System Description: Activity Beacon Description and Usage of the Activity Beacon

The activity beacon is designed as a small wireless, battery-powered device placed around the home to serve as a prompting device. For example, Nancy, daughter of Frank, 78, puts an activity beacon on top of the refrigerator, next to where Frank keeps his meds. If Frank has not taken his medications by 9 a.m. (as sensed by a motion sensor or other device), and the sensor network knows that he is up and about, the server sends a message to the activity beacon to prompt Frank. The activity beacon starts to blink its LED. If, after 10 minutes, Frank still has not taken his medicine, the beacon starts to emit periodic beeps. Frank can press a button on the device to turn off the LED/beeper (the Stop button), or he can press the Play button and hear a short message recorded by Nancy, “Dad, remember to take your blood pressure pills!” 8.11.3.2

General Usage and Requirements

The activity beacon is designed as both an audio and visual prompting device. The audio is a small speaker that delivers previously recorded voice and a beeping sound. The visual prompting is blinking LEDs to help the user locate the beeping sound. The combination of audio and video prompts is referred to as a prompting

8.11 Prototype Definition Requirements Document

181

program. The beacon is placed in a prominent position, to maximize its reminder value; multiple beacons may be deployed in a single home. 8.11.3.3 •

• •

•

• • •

Activity Beacon Requirements

Audio. The playback of a short recorded speech message is required. So is the generation of a beeping alert. Buttons. The beacon should have two buttons: a Stop and a Play. Stop button. The Stop button cancels the prompting program in progress, and sends a message back to the server that the program has been canceled. Play button. The Play button plays the stored sound file for the current prompting program (there may be more than one program for an activity beacon). Pressing the Play button will also cancel the prompting program in progress and send a message back to the server that the sound file has been played. LED. Single-color LED, has three states—Off, On, and Blinking. Size. Smaller size is better. Battery life. Longer battery life is better.

To conserve battery life, the activity beacon can go into a sleep state where the radio only wakes up occasionally. For example, if the prompting program can only occur in the morning (e.g., morning meds reminder), the beacon can go into a sleep state for the rest of the day, waking up occasionally to check for new instructions, and then waking up fully when the morning prompting program might go into effect. •

Radio. The longest possible range is preferred. •

•

•

The radio should be able to operate effectively around metal appliances, chairs, etc.

Communication. The home server can download sound files (up to 20 seconds in length) and can download prompting programs in advance. When a prompting condition occurs, the server sends a message to the beacon telling it which prompting program is in effect (see programming options, below). Programming options. Each prompting program may include the following options: •

LED on (duration on). The LED turns on and remains on until the Stop button is pressed or the duration times out (or until a signal from the server?).

•

LED on, blink (duration on, duration blink). The LED turns on for (duration on), then begins to blink for (duration blink). Turns off after (duration blink), or if the Stop button is pressed.

•

LED on, blink, beep (duration on, duration blink, duration beep): The LED turns on for (duration on), then begins to blink for (duration blink), then blinks and beeps for (duration beep). Turns off after (duration beep), or if the Stop button is pressed.

•

LED blink (duration blink).

182

Contextual Awareness Medication Prompting Field Trials in Homes

•

LED blink, beep (duration blink, duration beep).

•

Play Sound File. Plays the sound file, blinks the LED while the sound file plays.

For all programming options (except Play Sound File), the sound file can be played when the Play button is pressed. Playing the sound file cancels the prompting program. Prompting programs can have a time frame assigned to them to conserve battery life (see battery, above).

8.11.3.4

Enclosure

Requirements • • • •

LED: Single-color, three states on/off and blinking. Battery life: Longer is better. Speaker: Audio-prompting device. Buttons: Two buttons, stop and play. •

Stop will cancel the prompting program.

•

Play will play the stored sound file.

Design Choices • • •

Design for both wall powered and battery use; Lightweight (around 7 oz). Embedded Processors: The activity beacon (Figure 8.24) has embedded processors for: •

Speech: VR stamp (Figure 8.25).

•

Wireless communications: Telos motes.

•

Battery recharge: BQ241014DRC.

8.11.4 8.11.4.1

System Description: Phone Sensor Requirements

The phone sensor must detect the following: • •

Phone receiver lifted; Phone receiver replaced;

The phone sensor must communicate this information to the home server laptop. 8.11.4.2

Design Choice

The commercial Whozz Calling device was selected. The device plugs into an unused phone jack near the home server laptop, and detects incoming and outgoing

8.11 Prototype Definition Requirements Document

Figure 8.24

Activity beacon enclosure.

Figure 8.25

Sample VR stamp.

183

phone activity in the house. It interfaces to the PC through a serial port. The sensor reports rings, on/off-hook, phone number dialed, and caller ID info. For the CAMP trials, the phone number information is not used. To respect participant privacy, the phone number information was never recorded at any level in the system. 8.11.5 8.11.5.1

System Description: Bed Sensor Requirements

The bed sensor must detect: • •

Time of going to bed (possibly many times per night); Time of rising (possibly many times per night).

The bed sensor must communicate bed data to the home server laptop.

184

Contextual Awareness Medication Prompting Field Trials in Homes

The bed sensor must be configurable to set thresholds for in-bed and out-of-bed. 8.11.5.2

Design Choice

The bed sensor chosen was a Bluetooth modification of the commercially available Tactex bed sensor, which sits under the mattress to unobtrusively monitor motion in the bed. The sensor operates in one of two modes: 1.

Full data. In this mode, the sensor sends a continuous stream of raw pressure data points in a grid.

2.

Restlessness. In this mode, the sensor periodically sends a restlessness measure and an in-bed/out-of-bed indication.

For the CAMP study, this device was used in Restlessness mode, to record the quality of sleep (assumed from restlessness), and whether the person is in or out of the bed. As part of the sensor configuration, the per-household pressure threshold was set for determining in/out of bed for each household. 8.11.6 8.11.6.1

System Description: Motion Sensor Requirements

•

The motion sensor must detect movement in the room where the sensor is located.

•

The motion sensor must communicate this information to the home server laptop.

8.11.6.2

Design Choice

The RFX10 Motion Sensor was chosen. Each sensor uses a passive infrared (PIR) detector to sense motion of people across its field of view. It sends an RFX10 On message when it sees initial motion, and every 7 to 10 seconds that motion continues, then it sends an RFX10 Off message sometime after motion has ended. In our experience, the Off message is not a reliable means of detecting the end of motion; instead, a lack of On messages was used to infer the end of motion. Messages are received via a serial cable connected to an RFX10 base-station, available commercially. The protocol is primitive, requiring error detection, duplicate-packet detection, and packet resynchronizing in the system software. The messages do not contain a time stamp, so the system software time stamped each message when received. A motion detector may see into another room, and so fire on motion in that other room.

8.12 Software: The Inference Engine

8.11.7 8.11.7.1 •

•

•

185

System Description: Door Sensor Requirements

The door sensor must detect opening and closing of the door to which it is attached. The door sensor must be suitable for both the front door and the refrigerator door. The door sensor must communicate this information to the home server laptop.

8.11.7.2

Design Choice

The RFX10 Switch Sensor was chosen. Each sensor uses a magnetic reed switch to detect when a particular door is opened or closed. When the door is opened, an RFX10 On message is sent; when the door is closed, an Off message is sent. As with RFX10 Motion Sensors, messages are received via a serial cable connected to an RFX10 base station, available commercially. Unlike the motion sensors, the RFX10 Switch Sensors randomly pick their ID each time their power is reset. Each time that happened, the system software configuration file had to be manually updated to reflect the new ID. Because of mechanical difficulties in mounting the reed switch on refrigerators, some refrigerators’ sensors sent an On message when closed and an Off message when opened—the opposite of the normal situation.

8.12

Software: The Inference Engine A key aspect of the solution is its ability to be sensitive to context—the location and activity of the subject. In order to achieve this, the solution must carry out real-time analysis of sensor information. An appropriate combination of sensor data for each location and/or activity must be established, and an “inference engine” must then be created which extracts the context information from the sensor data. This section lists the list of activities to be detected or inferred and the inputs that are analyzed to reach an inferred conclusion. 8.12.1

1. 2. 3. 4. 5. 6. 7.

The Total Set of Activities to Be Detected or Inferred

Travel: for example, a vacation. Errand: leaving the house for a short time. Visitor: people coming to the house to visit. Phone call Early appointments: earlier-than-normal patterns of activity, followed by early exit from the house. Preparing food or drink. Sleeping: both length and quality of sleep.

186

Contextual Awareness Medication Prompting Field Trials in Homes

8. Location: of the participant within the house. 9. Whether the participant has taken a medication. 10. Time of day/day of week. 8.12.2

Activities Affecting Adherence

The following are the most likely causes of a person missing a meds dose. All are elaborations of the basic cause: disturbances in the participant’s routine: 1. 2. 3. 4. 5. 6. 8.12.3

Travel. Visitors. Phone calls. Early appointments. Distractions from the kitchen—preparing or eating meals, snacks, and drinks. Sleep—quantity and quality. Activities Affecting Ability to Respond to Prompts

We define context-aware prompting as the delivery of prompts at the right time, place, and during the appropriate activity. To do that, the system must detect the following additional activities, which either interfere with or enhance the participant’s ability to respond to a prompt: 1. 2. 3. 4. 5.

8.12.4

Errands—being out of the house. Visitor in the house. Phone calls—being on the phone. Asleep—being insensible to prompts. Location—being at a place that is either convenient or inconvenient (e.g., in the kitchen versus the bathroom). Other Significant Effects to Detect

Beyond the set of activities to detect or infer, there is a small set of other activities or qualities to additionally detect or measure in order to more successfully predict adherence and successfully prompt the participant: 1. 2. 3.

8.12.5

Whether the participant has taken the current dose yet. The time of day—to determine the window of time for the dose. The day of the week—to detect probabilities that are bound to the day of the week (e.g., weekday versus weekend behavioral and schedule changes). Some Candidate Effects Not Detected

There are a set of effects that we have decided to not detect or infer, even though they seem easy to detect with our sensor set, because we determined them to not be significant causes of missing meds.

8.12 Software: The Inference Engine

1. 2. 3. 4.

187

Sleeping late. Rising early (see early appointment, below). Eating late or skipping meals. Illness (sleeping late, staying in bedroom and bathroom).

Here are the things we can detect: 1. 2. 3. 4. 5. 6. 7. 8. 8.12.6

Unexpected phone calls. Early appointments. Travel with iMedTracker (will not prompt). Not colocated with iMedTracker. Visitors. Distractions in the kitchen. Sleep quality—poor sleep might raise the probability of nonadherence. Time and day. Sensors and Actuators to Be Deployed

The following sensors and actuators are deployed in each household: 1. 2. 3. 4. 5. 6. 7. 8.12.7

iMedTracker—pill box. Health SPOT watch—location and prompting. Up to three activity beacons—distributed prompting. Whozz Calling—phone call logger. Tactex-based bed sensor. RF X10 motion/light detectors—one per room plus one outside the door. RF X10 door switches—one on the front door, one on the fridge door. Types of Inference

There are several inference components. One type of inference is responsible for inferring the location of the participant based on sensor data. Another infers the likelihood of missing a dose, based on sensor data and history. Another infers the likelihood of a prompt being effective, based on sensor data and history. 8.12.7.1

Detection or Inference of Activities

This section describes, for each activity or quality to be detected or inferred, how that may be detected or inferred from data from the chosen set of sensors. The following terminology is used: • •

•

Detected: The sensor outputs the information we want. Determined: Sensor outputs are combined via a nonstatistical algorithm to produce the information we want. Inferred: The sensor outputs are combined with other sensor outputs and historical data to produce a probability that the desired activity is happening.

188

Contextual Awareness Medication Prompting Field Trials in Homes

•

Calculated: The information we want is derived without sensor data.

Travel—Determined: iMedTracker, SPOT, Motion, Front Door

We define travel as the participant being out of the house with the iMedTracker. This state can be inferred by any of the following sensor data: 1. 2. 3.

iMedTracker is no longer detected. Health SPOT watch is no longer detected and iMedTracker is no longer detected. Front door closes, followed by no motion in the house (true only if the participant lives alone).

Errand—Determined: iMedTracker, SPOT, Motion, Front Door

We define an errand as the participant being out of the house without the iMedTracker. This can be inferred in a similar way to Travel, except that the iMedTracker is detected as still being in the house. Visitor—Determined: Motion, Front Door, SPOT

A visitor entering the house is implied by the following sequence: 1. 2. 3. 4.

Motion outside the front door and motion inside the front door. The door opening. The door closing. Motion inside the house.

A visitor being in the house is implied by occasionally detecting noncontiguous motion in the house—that is, a sequence of motion detection that requires multiple people. For example, if the bedroom motion detector fires, then the living room motion detector fires, without the intervening hallway motion detector firing, there are likely two people (or a pet) in the house. This method will not work in the common situation of the resident staying in the same room as the visitor for the duration of the visit. A visitor leaving the house is implied by the following sequence: 1. 2. 3. 4. 5.

Motion inside the front door. The door opening. Motion outside the front door. The door closing. Motion inside the house.

These sequences are ambiguous. If the watch provides adequate time-and-space location resolution, it may be possible to infer that there is more than one person in the house based on motion in a room that the watch is not in. For purposes of correlating with the missing of meds, it may be sufficient to simply examine timing and frequency of front door openings to determine whether the participant’s pattern of activity is sufficiently interrupted to miss a dose.

8.12 Software: The Inference Engine

189

Phone Call—Detected: Whozz Calling

The Whozz Calling phone sensor generates a serial message when any phone on that line rings, when the phone goes off-hook, when the phone goes on-hook, and a number of other parameters. Only the ring and hook information are used to determine the timing of phone calls. Other parameters, such as caller ID, are not recorded, in order to protect privacy. Early Appointment—Inferred: All Sensors

“Early Appointment” encompasses a variety of disruptions of the participant’s morning pattern of activity. We define an early appointment as the pattern of morning activity shifting earlier in the day, typically ending in leaving the house earlier than normal. Early appointments can be inferred from the bed sensor, fridge sensor, and location of the participant over time. Preparing Food or Drink—determined: SPOT, Fridge Door, Kitchen Motion

The RF X10 door detector on the fridge detects when the fridge is opened. Preparing food or drink must be inferred by the combination of fridge door sensor and either the SPOT watch or the kitchen motion sensor. Sleeping—Determined: Tactex Bed Sensor

The Tactex-based bed sensor sits under the mattress (or one side of a double-sized mattress) and detects the pressure on the mattress in a grid, over time. Tactex has algorithms to convert the signal over time into both presence in bed and activity in bed (related to quality of sleep). We recognize that the sensor does not detect actual sleep. Some difficult cases: reading in bed; sleeping in a chair in the living room. Location of Participant—Inferred: SPOT, Motion Detectors

The Health SPOT watch is designed to enable inference of the location of the wearer via radio signal strength indicator (RSSI): A Bluetooth master can periodically measure the strength of the Bluetooth signal produced by the watch, and infer the range of possible location from that signal strength. There are a handful of issues which raise the risk that the Health SPOT watch RSSI algorithm will not locate the wearer with sufficient accuracy: 1.

2.

RSSI can be measured only by the single Bluetooth master, rather than at multiple measurement points. Radio signal strength location algorithms were developed assuming a minimum of three RSSI measurements locations; the theoretical minimum required to locate a point geometrically within a plane. Practically, because of noise in the measurement and nonlinearities caused by signal reflection and absorption in the house, more than three RSSI measurement locations are typically used. Bluetooth radios adapt their signal strength to the quality of the connection. This effect could produce a nearly constant RSSI as the participant moves about, instead of an RSSI that is inversely proportional to the distance between the participant and the RSSI measurement point(s).

190

Contextual Awareness Medication Prompting Field Trials in Homes

3.

Bluetooth signal strength is measured periodically. The period may be on the order of a minute. In contrast, a participant can move at a few feet per second.

If testing of the Health SPOT watch shows that it provides inadequate location information, the location of the subject can be inferred from the RF X10 motion detectors and door detectors. This backup plan works only if the participant lives alone, and it may produce ambiguous results when a visitor is in the house. Whether Participant Has Taken a Dose—Determined: iMedTracker

Because of the complexity of verifying actual consumption of a pill, we define taking a dose as opening the appropriate bin lid of the iMedTracker. We do not consider whether the participant actually removes the pill and swallows it. The iMedTracker sends a Bluetooth message whenever one of its bin lids is opened or closed. In the simple case, taking a dose is simply opening the appropriate bin lid. A deterministic (nonstatistical) algorithm needs to be designed that infers that a dose has or hasn’t been taken, given possible sequences of lid openings and closings. For example, a participant may open the wrong lid and take the pill from that bin, or may open the wrong lid, close it and open the correct lid. Time of Day / Day of Week—Calculated

The PC keeps track of date and time, and can separate out local day of week and local time of day (Figure 8.26).

8.13

Reasoning System for Context-Aware Prompting An important subproject within CAMP was the development of a reasoning system that could use sensor-generated data to come to conclusions about the subject’s context. An important aspect of CAMP was context-awareness: that subjects would be prompted to take their medications when it was convenient or feasible for them to do so. Existing time-based prompters, for example, take no account of the physical location of the subject; an alarm clock ringing in an empty house does not have any value as a prompt. Another, more challenging task is to identify when a subject is about to leave the domestic environment, and to prompt them to bring their medication along, or to take it early. Context-aware prompting using a reasoning system was implemented within the CAMP initiative by a team of researchers from Intel and Oregon Health and Science University [51]. The implementation was of scientific interest because it demonstrated the long-term (several months) deployment of a reasoning system in the real world beyond the laboratory environment. It also identified and addressed practical engineering issues such as sensor noise and intermittent gaps in the available data, and their impact on the design of the reasoning system. The scientific objective was to identify (a) the location of the subject at any given time and (b) when the subject was about to leave the house or apartment. The inputs to the reasoning system were data feeds from the network of motion sensors and door sensors within the home; the location of the subject was taken to be the

8.13 Reasoning System for Context-Aware Prompting

191

Above Threshold? H0 Will miss meds

iMed Tracker Taking meds sets H

Time

0=

Poor sleep

Model

Bed sensor

Refrig door

Prompt

0

Kitchen Distractions

Early Appt.

Visitors

Model

Model

Model

Motion

Spot

Front Door

Phone call

Model

Telephone

Figure 8.26 Time and day history incorporated into the models.

location of the most recently fired motion sensor. A number of different sensor inputs could suggest that the subject was preparing to leave; these included a generally high level of movement around the apartment, extended time spent near the front door, and of course the opening of the front door itself. The variables are shown in Table 8.7. The context model for the reasoning system used sensor-observed data over defined timeslices as its key input. The timeslices were rather short (5 seconds), in order to be able to identify the brief events which take place before the subject leaves the home. The outputs of the reasoning system (its hidden variables) were the location of the subject, and an indication of leaving. Two reasoning models were considered—a dynamic Bayesian network (DBN) and a deterministic rules-based approach. Several variations of the DBN were created, and the results for each model were compared, in order to establish which model best generated reliable “location” and “leaving” values on the basis of sensor data inputs. Two examples of the DBN are shown in Figure 8.27. The dotted line in the diagram separates two time slices, “now” and “five seconds from now,” while the arcs across the dotted line show temporal conditional dependencies across variables. The second model (Model #4) performed best; note its link between leaving and location, which reflects the real-world reality that the subject is unable to leave unless his or her location is at the front door. When past values of variables were ignored, so that the model was simplified to a conventional Bayesian network for each time slice, the location value continued to be well detected. A rule-based system was also tried, and it had significant levels of failure due to sensor noise. For example, the kitchen sensor sometimes fired when the front door opened, due to the proximity of the kitchen to the hall. This led to the system assuming that, having opened the door, the subject had returned to the kitchen, and so had not gone out after all. As a result, no “please take your medication before you

192

Contextual Awareness Medication Prompting Field Trials in Homes

Table 8.7

Model Variables and Their Possible Values

Variable

Values

Comment

Location

NotHome, Bedroom, Kitchen,

Hidden variable

Livingroom, Bathroom, Frontdoor

Hidden variable

Leaving

True, False

Hidden variable

LastMSFiring

MS1, MS2, . . . , MSN

Which motion sensor (MS) was fired last?

MSFiringsFreq

None, L(1-2), M(3-5),

Num. MS firings in last 1 minute

MSTransitions

None, L(1-5), M(6-10),

H (more than 5) Number of MS transitions in last 5 minutes

High(more than 10) Bed

In, Out

DoorEvent

OpenEvent, CloseEvent, NoEvent

Refrigerator

OpenEvent, CloseEvent, NoEvent

Time

EM (6–9 a.m.), MM (9–11 a.m.), Noon (11–2 p.m.), A (2–5 p.m.), E (5–9 p.m.), Night (9 p.m.–6 a.m.)

99%

78%

65%

54%

99%

84%

69%

44%

Figure 8.27

Two examples of the DBNs.

leave” prompt was issued to the subject; in addition, the system remained unaware that the subject was out of the home. The requirement for dealing with noise complicates rules based systems. Naïve-type Bayesian networks were easy enough to

8.14 Explanation of Location Tracking Using the Health SPOT Watch

193

use, and generated fair results—the research team concluded that a good set of rules for a deterministic reasoning system is unlikely to be easier to develop. Sensor anomalies (e.g., sensor drift) also added challenges to the reasoning system; the system does not deal well with sudden unavailability of sensor data. The team dealt with this by manual filtering of the sensor data before it was consumed by the reasoning system. Clearly, this is not scalable, and some thresholding and preprocessing is expected to be needed in order to improve performance. The overall results of the reasoning system work were that: •

•

•

8.14

A statistical (Bayesian) model is promising for this type of project. While it is possible that vulnerabilities in the rule-based model could be addressed by adding additional rules, the team believed that it would be difficult to create a sufficiently robust set of rules, and that the use of a Bayesian approach would be more efficient. A reasoning system can be effective as a key part of an independent ageing support solution. The system was deployed over an extended period of time across several households (n=12, declining to n=6 over the course of the project). Adherence to medication regimen improved by over 30% when compared to a no-prompting environment, and by 17% when compared with conventional, time-based reminders. The reliability of the sensor technology and of the communications links between the reasoning engine and the sensors is of paramount importance, if the reasoning engine is to function optimally. In situations where anomalies occur, the statistical (Bayesian) model appears to be more robust than a deterministic, rules-based model.

Explanation of Location Tracking Using the Health SPOT Watch Mobile location tracking enables the provision of services at the right place and the right time; several applications can be developed based on location. In the study, we attempt to provide prompting for medication adherence that is both time- and location-sensitive (i.e., contextually aware medication prompting). In order to provide such a service, it is necessary to locate the user within the indoor space, which is typically a common house or apartment setting. This gives rise to the question of location tracking within a small area of interest. Previous trials of medication reminding systems have shown problems when the systems are based on temporal elements only and do not take into account the context or spatial location of the person to be reminded. The purpose of the new Health SPOT device is to use the device as both a location tracking device and a prompting device. The Health SPOT is a modification of the SPOT Watch sold to support MSN Direct communication to SPOT devices. The research prototype in this program will be a commercially available watch with an incorporated Bluetooth module tied to the UART of the embedded processor in the device. The device will be used to track elders in their homes. This tracking is targeted a room level location. The location inside the home is accomplished by mapping received signal strength indication (RSSI) and bit error rate (BER) on a Bluetooth radio link

194

Contextual Awareness Medication Prompting Field Trials in Homes

between a sensor and a base station to the spatial coordinates of the home. The modified watch will send out periodic beacons at a specified time and wait for an acknowledgement (ACK) message from the contextual aware medication prompting (CAMP) system. The CAMP system will analyze the RSSI and BER of the BT radio to establish the position of the elder in the home. If the elder leaves the home, the modified watch will begin logging the various FM broadcast signal strengths. The embedded processor in the modified watch will average the various samples and include a time stamp for the average. These averages of 10 towers and time stamp for each location read will stored in the memory of the embedded processor on the watch. Once the Health SPOT has received an ACK message again in the home, the average RSSI numbers and times will be downloaded from the watch to the PC in the home. The watch will store up to 6 hours of RSSI data when the watch is outside the home. If the watch is outside the home more than 6 hours, no more data will be collected from the FM towers. 8.14.1

Literature Review

Among the location-tracking technologies already in popular use are GSM and GPRS. These systems rely on satellite communication and use triangulation to establish position; thus they are useful for outdoor tracking on a large scale. However, commonly available GPS devices do not usually work indoors because of line of sight issues, and are not sensitive enough to detect the small changes in distance within a small area. High-sensitivity devices that can measure distance changes within a meter are more costly and are cannot be considered the best solution for indoor space. 3G networks and Bluetooth networks offer alternatives with different pros and cons [6]. IEEE802.11a, b, and g are the common wireless LAN standards in use today. However, in order to provide location based services, there is a need to be able to form ad hoc networks with devices leaving and entering randomly. This is not easily accomplished by using 802.11 standard devices such as access points since there are requirements for IP addresses and other considerations such as power requirements. Bluetooth networks on the other hand were developed primarily for the purpose of short-range ad hoc networks for use in cell phones and other mobile devices. The Bluetooth protocol uses low-power signals that offer the advantage of longer battery life for the portable devices. Also, since these networks operate in the frequency range of the ISM band, they are free to use. The problem lies in ensuring that the significant amount of wireless traffic now common in urban locations does not interfere with the Bluetooth signals. In order to avoid this, the technique of frequency hopping is used. This ensures that no two devices within the network are transmitting at the same frequencies. Thus there are some distinct advantages of using Bluetooth for indoor location tracking purposes. Location tracking in general employs one of two methods, using line of sight differences in order to triangulate, or measurement of the received signal strength indication from wireless networks, since these have become increasingly commonplace for the modern user. One possibility is to use RSSI as a means to triangulate the position of sensor itself by using multiple access points but this increases the cost

8.14 Explanation of Location Tracking Using the Health SPOT Watch

195

of the system. Even in cases where RSSI from a single access point is being utilized there is considerable effort involved in characterizing the indoor space [2]. 8.14.2

RSSI and BER for Location

Instead of using triangulation, we propose that location can be established by finding unique combinations of RSSI and BER for the space under consideration. Received signal strength typically shows a uniform decay as distance increases, provided this it is measured in an open space. Even with the presence of walls RSSI can be used as a parameter in determining the distance of a transmitter from a receiver. However RSSI alone is not sufficient to locate a transmitter in space since the RSSI value measured could be the same for multiple points all lying equidistant from the receiver, or the effects of walls and other obstacles may dampen the RSSI from a closer point, making it look similar to a point more distant from the receiver. What is required is another independent parameter that varies with location. BER, which is the number of packets lost during transmission, can be used for this purpose [3]. Since BER is inversely related to the link quality (LQ), either one can be used as the second parameter. Although it is possible for different locations to have similar values for RSSI or identical LQ, the probability of the combination of the two being the same is much less. The reason for this is because the BER is affected by the number of reflections the transmitted wave undergoes, which is referred to as fast fading. The BER is also affected by slow fading, which is due to multipath effects. On the other hand, RSSI is more dependent on the distance between source and receiver and any obstacles that come directly in the way of the transmitted wave. With variation in the type, size, and amount of furniture, different arrangement of rooms and intelligent placing of the receiver, the likelihood of receiving similar combinations of RSSI & BER decreases further. Since the present study is related to medication prompting for people, it is convenient to use human behavioral patterns in order to narrow down the areas that need to be characterized. Since people spend relatively more time stationary than moving within their homes, we can use this premise to characterize those locations that are more favored by the user. Thus we provide a simple and efficient technique for characterizing indoor space based on the combination of the two mentioned parameters. 8.14.3

Health SPOT Device Construction and Software

Included in this section is the description of the embedded code and algorithm on the Health SPOT device. There are two additional embedded features to the watch that are not on the standard SPOT watches on the market. The first is the location stack software and the second is the prompting stack software. The following two sections discuss the pseudocode and algorithms for both. The Health SPOT device is intended to communicate through the BBV3. The location stack is broken into two segments. The first is the location in the home as detected by the RSSI or radio signal quality indicator through the Bluetooth module on the Health SPOT device. The indoor location tracking relies on two or more receivers for RSSI location awareness. This is an issue because the

196

Contextual Awareness Medication Prompting Field Trials in Homes

device that is the master can only have seven slaves in a piconet, so finding a position for a mobile device must mean that each stationary device is a slave to a mobile master. If portability is an issue then duty cycle wears down the battery life. Also other devices cannot communicate with the master to save data. A better architecture would be to have the mobile device as a slave in the network. The issue is the other slaves can not speak to the mobile slave. Figure 8.28 is a schematic of a floor plan for illustration. The RSSI is indicated by the color intensity of the gray background; the scales on the side are intended to represent the radio quality at the various levels working back from a base station in the upper-left corner of the kitchen. In this example the watch is Bluetooth-enabled and a base station (PC with BT) is in the kitchen. In Figure 8.28, the white line running diagonally through the floor plan represents lines of iso-RSSI. From this the reader may believe that the RSSI shows that the watch may be in the bedroom, bathroom, or the dining area without the ability to resolve the actual position of the device. In actuality this is idealized and not seen in most applications of RF technology. In most instances due to reflections, bounces, interference, and the inability of the RF to penetrate objects it may be much more complex. At best (without interference), this system would yield two or more possible positions for an RSSI reading from the mobile BT device. The complexity (fast versus slow fading) previously mentioned allows the inventor to make the claim of a unique, novel method for determining position from a single access point. This works by using two or more independent pieces of information about the status of the connection. There are various points in a home in which a radio signal is bounced, or partially blocked. This is unique to a home and position of the devices, and home construction and furnishings. As such the bit error rate, that is to say the collision of packets in transmission or failed to receive packets of RF content, is no longer solely

RSSI/BER to Distance

4

6

2

Distance Between Transmitter and Receiver (ft)

5

0 0

5

10

15

20

25

30

35

40

-2 4 -4

3

-6

-8 2 -10

-12 1 -14

-16

Figure 8.28

0

RSSI in the home.

8.14 Explanation of Location Tracking Using the Health SPOT Watch

197

a function of the radio signal strength, but also reflects the characteristics of the home environment. In free space or an open field, the RSSI decays as the receiver and transmitter distance grow apart proportional to an exponential power of 4. For example see the graph in Figure 8.29. So in free space the RSSI decays to the fourth power whereas the bit error rate increases linearly as the distance increases. The above data was taken on a pair of Bluetooth Blueradios SC30A in a field near Amber Glen in Hillsboro, Oregon. Using the same two radios when the test was repeated in the home, the BER becomes less tied to the distance and more tied to the amount of errors associated with multipath issues and interference in the home due to construction. This data is shown in Figure 8.30. Notice that the RSSI in Figure 8.30 falls as expected; the unique signature from the wall edge at 12 and 22 feet from the base station is seen in the BER. So the combination of RSSI and BER in the home can give a unique signature of the position of a signal pair transmitter and receiver (Figure 8.31). As the receiver trends farther from the transmitter, the RSSI-only method actually increases in error while the opposite is true for using the combined method discussed here. This error also decreases when an architectural obstacle (wall or partial wall) is in the direct path of the receiver and transmitter. In this case, the BER actually increases due to these structures. This experiment was repeated using the Bluetooth radio in SPOT watch format using the following algorithm to identify a person’s location at any time. The error in the two methodologies is shown in the chart below for the in home test. 35.00%

Error in RSSI only and BER+RSSI

30.00%

25.00%

%E rror

%Location error with BER %Location error Using Just RSSI 20.00%

15.00%

10.00%

5.00%

0.00% 0

5

10

15

20

Distance (feet)

Figure 8.29

RSSI decay and distance.

25

30

35

40

198

Contextual Awareness Medication Prompting Field Trials in Homes

RSSI/BER in Main Room 0

0.0035

-2 0.0025

-3 -4

0.002

-5 0.0015

-6 -7

0.001

-8 0.0005

-9

0 0

5

10

15

20

25

30

Feet from Base Station

Figure 8.30

Error and RSSI.

Figure 8.31

RSSI and BER in the main room.

The following algorithm was implanted in the watch device:

35

-10 40

R SS I(dB)

Average B ER CS R Algorithm

-1 0.003

8.14 Explanation of Location Tracking Using the Health SPOT Watch

199

Location Stack:

Transmit a BT Ping (consists of watch ser# and time), Wait X sec’s for reply RSSI log message format: Time, Avg.RSSI, AVG_BER, Watch Ser#, Sample# Continue to send until ACK’ed

If ACK received turn off BT radio Max ACK time 30 sec. – 1 min

For this algorithm, a map of a house is drawn up first to determine the BER and RSSI values for various rooms around the house. On the base station (PC or PDA) a lookup table is used to infer the position of a person in the home or building. For example, the map of the RSSI and the BER for a home is shown in Figure 8.32. The floor of the 3-D graph is the BER for the position and the height of the wire-frame is the RSSI. Effectively the X, Y position of the location has been mapped into RSSI/BER space for location. For higher confidence a third parameter such as transmit strength can be used. Once the device leaves the area of the apartment the Health SPOT will no longer receive an ACK signal from the base station PC. In this case the device will begin scanning the 10 FM towers in the area and logging the RSSI of the FM towers it reaches. The device will read each tower’s RSSI 50 times and average them, storing the average, before moving on to the next tower and repeating the process. This continues until there are 10 averages from the FM towers in the area. Once this is completed the Health SPOT attempts to reconnect to the BT network. If there is no ACK from the BBV3, the FM tower RSSI process should continue. Once the BBV3 and Health SPOT are reconnected, the FM RSSI information is downloaded to the PC via the BT network. The FM tower information can be used subsequently to infer the location of the Health SPOT outside the house. Location Stack: Ping (consists of watch ser# and time),

Wait TBD sec’s for reply If reply. Loop @ 30 sec interval No reply, Log FM RSSI DO FM TOWER(J) J=1,10 READ FM Tower(J) RSSI i=1,50 FM_TOWER_AVG(J) END DO Wait ~ 1 (TBD) min, then ping If reply, send RSSI Log, Loop Ping No Reply, Loop @ 5 (TBD) min FM RSSI RSSI log message format:

Time, Avg. RSSI, Tower ID, Watch Ser#, Sample# Continue to send until ACK’ed Max ACK time 30 sec. – 1 min (TBD)

200

Contextual Awareness Medication Prompting Field Trials in Homes

Have you taken your vitamins?

Figure 8.32

RSSI and BER data in the home.

All messages use ACK/NACK protocol between watch and base station. 8.14.4

Prompting Stack Pseudocode

To understand if the prompts are useful and can be received, Health SPOT will send prompts to the elder through the BT network. These prompts will be issued when the device is close to the iMedTracker and will be pushed forward on the display. Once the prompt is acknowledged, that information will be passed back to the PC over the BT network. Prompt Stack: Message from PC:

“String”, Ser#, Time Sent Sent until ACK’ed Watch: Push Prompt to Front Prompt Display “String”, “Yes”, ”No” Wait for a Response Watch Response: Prompt Status, Time of Prompt Button Pressed, Ser#

8.15

Conclusion In this case study we reviewed an independent aging research project (CAMP) that focused on reminding older persons to take their medication. The case study emphasized some important aspects of the WSN application: •

User requirements capture: Ethnography, use cases, a technology probe study, and collaborative design were all used as inputs to the design process.

8.15 Conclusion

•

•

201

Technical specification and requirements: the prototype definition requirements document (PDRD) for this system was covered in some detail. This key document defined the technology to be deployed and how it is to be used, and is central to any WSN application. There was a particular emphasis on the software—the use of an inference engine was considered, and the logic that enabled the system to be context-sensitive was described. This demonstrated how the information being gathered by sensors in a WSN can be used to inform decisions and to drive actuation.

Deployment of this solution is not described in any detail here. Much of the deployment/installation experience gained in this project is described in Chapter 6. From a clinical and patient perspective, the value of the CAMP project was significant. Overall, subjects with context-sensitive medication reminders remembered their medication over 30% more than those with no reminders, and 17% more than those who had time-based reminders. In addition, the system presented here was aware of when not to prompt—when the subject was asleep, on the telephone, or otherwise engaged. This meant that a positive response to the prompt was more likely; it also made the prompting service much more user-friendly and “considerate,” improving the prospects of its long-term adoption. From a research perspective, the project generated valuable insights into the design and long-term deployment of reasoning systems driven by sensor readings in a home environment, and into location tracking using single radio sources.

References [1]

[2]

[3]

[4]

[5]

[6]

García Castaño, J., M. Svensson, and M. Ekström, Local Positioning for Wireless Sensors Based on Bluetooth,” 2004 IEEE Radio and Wireless Conference, Sept. 19–22, 2004, pp. 195–198. Seshadri, V., G.V. Zaruba, and M. Huber, “Bayesian Sampling Approach to Indoor Localization of Wireless Devices Using Received Signal Strength Indication,” Third IEEE International Conference on Pervasive Computing and Communications, PerCom 2005, March 8–12, 2005, pp.75–84. Yang; S.- H., Y.- H. Lee, and R. Y. Yen, et al., “A Wireless LAN Measurement Method Based on RSSI and FER,” APCC/OECC ’99. Fifth Asia-Pacific Conference on ... and Fourth Optoelectronics and Communications Conference, Oct. 18–22, 1999, Vol. 1, pp. 821–824. Ji, X., and H. Zha, “Robust Sensor Localization Algorithm in Wireless Ad-Hoc Sensor Networks,” Proceedings. The 12th International Conference on Computer Communications and Networks, ICCCN 2003, Oct. 20–22, 2003, pp. 527–532. Alippi, C., and G. Vanini, “Wireless Sensor Networks and Radio Localization: A Metrological Analysis of the MICA2 Received Signal Strength Indicator,” 29th Annual IEEE International Conference on Local Computer Networks, Nov. 16–18, 2004, pp. 579–580. Thongthammachart, S., and H. Olesen, Bluetooth Enables Indoor Mobile Location Services,” 57th IEEE Semiannual Vehicular Technology Conference, VTC 2003–Spring, April 22–25, 2003, Vol. 3, pp. 2023–2027.

202

Contextual Awareness Medication Prompting Field Trials in Homes [7]

[8]

[9]

[10]

[11] [12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22] [23]

Gonzalez-Castano, F. J., and J. Garcia-Reinoso, “Bluetooth Location Networks,” Global Telecommunications Conference, GLOBECOM ’02, Nov. 17–21, 2002, Vol. 1, pp. 233–237. Gonzalez-Castano, F. J., and J. Garcia-Reinoso, “Survivable Bluetooth Location Networks,” IEEE International Conference on Communications, ICC ’03, May 11–15, 2003, Vol. 2, pp. 1014–1018. Hiramatsu, A., N. Kawamura, and Y. Takada, et al., “Operation Support for the Location-Aware Exhibit Information Service System Using Bluetooth Communication,” IEEE International Conference on Systems, Man and Cybernetics, Oct. 5–8, 2003, Vol. 4, pp. 4051–4056. Paiidya, D., R. Jain, and E. Lupu, “Indoor Location Estimation Using Multiple Wireless Technologies,” 14th IEEE Proceedings on Persona1, Indoor and Mobile Radio Communication, PIMRC 2003, Sept. 7–10, 2003, Vol. 3, pp. 2208–2212. Schulzrinne, H., X. Wu, and S. Sidiroglou, et al., “Ubiquitous Computing in Home Networks,” Communications Magazine, Vol. 41, No. 11, Nov. 2003, pp. 128–135. Vermeeren, G., H. Rogier, and F. Olyslager, et al., “Simple Low-Cost Planar Antenna for Indoor Communication under the Bluetooth Protocol,” Electronics Letters, Vol. 37, No. 19, Sept. 13, 2001, pp. 1153–1154. Alicherry, M., H. Nagesh, and C. Phadke, et al., “Balancing the Accuracy and Practicality of Location Tracking in Heterogeneous Mobile Networks,” Global Telecommunications Conference, GLOBECOM ’04, Nov. 29–Dec. 3, 2004, Vol. 5, pp. 3316–3320. Kim, Y., and B. Zhen, “Connectionless Boadcast Channel and Mobility of Bluetooth,” IEEE 55th Vehicular Technology Conference, VTC Spring 2002, May 6–9, 2002,Vol. 2, pp. 918–922. di Flora, C., M. Ficco, and S. Russo, et al., “Indoor and Outdoor Location Based Services for Portable Wireless Devices,” 25th IEEE International Conference on Distributed Computing Systems Workshops, June 6–10, 2005, pp. 244–250. Li, X.-Y., I. Stojmenovic, and Y. Wang, “Partial Delaunay triangulation and Degree Limited Localized Bluetooth Scatternet Formation,” IEEE Transactions on Parallel and Distributed Systems, April 2004, Vol. 15, No. 4, pp. 350–361. Hallberg, J., M. Nilsson, and K. Synnes, “Positioning with Bluetooth,” 10th International Conference on Telecommunications, ICT 2003, Feb. 23–March 1, 2003, Vol. 2, pp. 954–958. Bandara, U., M. Hasegawa, and M. Inoue, et al., “Design and Implementation of a Bluetooth Signal Strength Based Location Sensing System,” 2004 IEEE Radio and Wireless Conference, Sept. 19–22, 2004, pp. 319–322. Youssef, A., J. Krumm, and E. Miller, et al., “Computing Location from Ambient FM Radio Signals [Commercial Radio Station Signals],” 2005 IEEE Wireless Communications and Networking Conference, March 13–17, 2005, Vol. 2, pp. 824–829. Krishnamoorthy, S., J. H. Reed, and C. R. Anderson, et al., “Characterization of the 2.4 GHz ISM Band Electromagnetic Interference in a Hospital Environment,” Proceedings of the 25th Annual International Conference of the IEEE Engineering in Medicine and Biology Society, Sept. 17–21, 2003, Vol. 4, pp. 3245–3248. Zaruba, G. V., M. Huber, and F.A. Karnangar, et al., “Monte Carlo Sampling Based In-Home Location Tracking with Minimal RF Infrastructure Requirements,” Global Telecommunications Conference, GLOBECOM ’04, Nov. 29–Dec. 3, 2004, Vol. 6, pp. 3624–3629. Howitt, I., “Mutual Interference Between Independent Bluetooth Piconets,” IEEE Transactions on Vehicular Technology, May 2003, Vol. 52, No. 3, pp. 708–718. Dent, D., “Bluetooth Wireless Technology by Online Learning,” 32nd Annual Frontiers in Education, FIE 2002, Nov. 6–9, 2002, Vol. 3, pp. S1E-19–S1E-23.

8.15 Conclusion

203

[24] Chong Liu; Kui Wu; Tian He; “Sensor Localization with Ring Overlapping Based on Comparison of Received Signal Strength Indicator,” Mobile Ad-hoc and Sensor Systems, 2004 IEEE International Conference on, 25–27 Oct. 2004, pp. 516–518. [25] Chen, L.- J., R. Kapoor, and M. Y. Sanadidi, et al., “Enhancing Bluetooth TCP Throughput Via Link Layer Packet Adaptation,” 2004 IEEE International Conference on Communications, June 20–24, 2004, Vol. 7, pp. 4012–4016. [26] Alag, S., K. Goebel, and A. M. Agogino, “A Methodology for Intelligent Sensor Validation and Fusion Used in Tracking and Avoidance of Objects for Automated Vehicles,” Proceedings of the American Control Conference, June 21–23, 1995, Vol. 5, pp. 3647–3653. [27] Enhancing Wireless Device Discovery and Connection Setup Using Radio Hierarchies. [28] Bluetooth Specification V 1.1. [29] Sabate, E. (ed.), Adherence to Long-Term Therapies, Evidence for Action, World Health Organization, 2003, pp. 33–57. [30] Berger, B. A., et al. (eds.), Medication Digest: Compliance-Adherence-Persistence, American Pharmacists Association, Auburn, Alabama, 2003, pp. 1–32. [31] Andrade, A., H. McGruder, and A. Wu, et al., “A Programmable Prompting Device Improves Adherence to Highly Active Antiretroviral Therapy in HIV-Infected Subjects with Memory Impairment,” Clinical Infectious Diseases, Vol. 41, 2005, pp. 875–882. [32] Botelho, R., and R. Dudrak, II, “Home Assessment of Adherence to Long-Term Medication in the Elderly,” Journal of Family Practice, Vol. 35, No.1, 1992, pp. 61–66. [33] Claxton, A., J. Cramer, and C. Pierce, “A Systematic Review of the Associations Between Dose Regimens and Medication Compliance,” Clincal Theraputics, Vol. 23, No. 8, 2001, pp. 1296–1310. [34] Cramer, J., R. Mattson, and M. Prevey, et al., How Often Is Medication Taken as Prescribed? A Novel Assessment Technique,” JAMA, Vol. 261, No. 22, 1989, pp. 3273–3277. [35] Demirbilek, O., and H. Demirkan, “Universal Product Design Involving Elderly Users: A Participatory Design Model,” Applied Ergonomics, Vol. 35, 2004, pp. 361–370. [36] Freeze, D. K., Umpqua Bank: Managing the Culture and Implementing the Brand, The Design Management Institute, Boston, MA, 2004. [37] Gage, M., and P. Kolari, “Making Emotional Connections Through Participatory Design,” accessed at http://www.boxesandarrows.com/archives/making_emotional_connections_through_participatory_design.php. [38] Gans, J., and T. McPhillips, Medication Digest: Compliance-Adherence-Persistence, American Pharmacists Assn. and Pfizer Corp., 2003. [39] Haynes, R. B., K. A. McKibbon, and R. Kanani, “Systematic Review of Randomised Trials of Interventions to Assist Patients to Follow Prescriptions for Medications,” The Lancet, Vol. 348, 1996, pp. 383–386. [40] Hutchinson, H., W. Mackay, and B. Westerlund, et al., “Technology Probes: Inspiring Design for and with Families,” Proc. ACM CHI, Vol. 1, 2003, pp. 17–24. [41] Lawton, M. P., and E. Brody, “Assessment of Older People: Self-Maintaining and Instrumental Activities of Daily Living,” The Gerontologist, Vol. 9, 1969, pp. 179–186. [42] Morris, M., J. Lundell, and E. Dishman, “Catalyzing Social Interaction with Ubiquitous Computing: A Needs Assessment of Elders Coping with Cognitive Decline,” Proc. ACM CHI 2004, Vienna, Austria, 2004, pp. 1151–1154. [43] Morris, M., J. Lundell, and E. Dishman, et al., “New Perspectives on Ubiquitous Computing from Ethnographic Study of Elders with Cognitive Decline,” Proceedings of Ubicomp 2003: Ubiquitous Computing. 227-242. [44] Nugent, C., D. Finlay, and R. Davies, et al., “Can Technology Improve Compliance to Medication?” in From Smart Homes to Smart Care, S. Giroux and H. Pigot (eds.), IOS Press, 2005, pp. 65–72. [45] Osterberg, L., and T. Blaschke, “Adherence to Medication,” N. Engl. J. Med., Vol. 353, 2005, pp. 487–497.

204

Contextual Awareness Medication Prompting Field Trials in Homes [46] Safren, S. A., E. S. Hendriksen, and N. Desousa, et al., Use of an On-Line Pager System to Increase Adherence to Antiretroviral Medications,” Aids Care, Vol. 15, No. 6, 2003, pp. 787–793. [47] Spiers, M. V., D. Kutzik, and M. Lamar, “Variations in Medication Understanding Among the Elderly,” American Journal of Health-System Pharmacists, Vol. 61, 2004, pp. 373–380. [48] Susman, E., “Notes and Quotes—A Pharmacist on Your Belt,” Aids, Vol. 15, No. 11, pp. N13–14. [49] Tan, H., and F. Chen, “A Conceptual Study of Prospective Audio Reminder as Cognitive Support for Medication Adherence of Elderly Adults,” Proc. XV Congress Int. Ergo. Assoc., pp. 540–543. [50] Wu, M., R. Baecker, and B. Richards, “Participatory Design of an Orientation Aid for Amnesiacs, Proc. ACM CHI, 2005, pp. 511–520. [51] Vurgun, S. M. Philipose, and M. Pavel, “A Statistical Reasoning System for Medication Prompting,” Proceedings of Ubicomp 2007, Innsbruck, Austria, September 2007.

CHAPTER 9

Case Study: Social Health 9.1

Introduction This chapter presents a final case study of the application of wireless sensor networks (WSNs) in healthcare. This case study looks at a project that investigated the relationship between social activity levels (sociality) and well-being, particularly as measured in terms of mild cognitive impairment. In the process, the project designed, built, and deployed a technology solution that collected information about social activity and encouraged greater sociality.

9.2

Clinical Problem Statement Patrick, 78, lives alone in an apartment. His week is active and socially busy, with his active retirement group and bowling club. His daily shopping trip brings him into contact with friends and acquaintances in the neighborhood. However, the weekends are rather lonely, and he tends to feel a little isolated and sad. Patrick’s son, Tom, lives across town. Tom is a schoolteacher, with a young family who keeps him busy both during the week and on the weekend. Tom describes his dad as happy and easy-going; he is not aware of Patrick’s empty weekends. Neither Tom nor Patrick is sure of the right time to get in touch; each fears to intrude on the other. Patrick does not like to call on the weekend, because he knows that Tom’s family takes up a lot of his free time. Tom is not sure when is a good time to call, and sometimes drives by his dad’s apartment, just to see if the lights are on. Patrick’s social activity and social health influence his mood and also many aspects of his physical and mental well-being. Social connectedness (sociality) has been strongly linked to mental and physical health, with more social people suffering less from serious illnesses such as dementia [1–3]. Unfortunately, later life in Western society often leads to a level of self-imposed isolation [4]. Social health, which is not so immediately apparent as mental or physical health, may be neglected or not taken into account by clinicians and caregivers; trends, changes, and fluctuations in social health are hard to detect and respond to. New tools and techniques are needed to characterize social health in terms of quantifiable metrics and to use these metrics to track, and respond to, changes in social health measures. Such new tools and techniques could help older people maintain their own social health; at the same time they could inform caregivers and ensure that appropriate levels of contact and of other forms of care are available for the elder. Wireless sensor networks, with their nonintrusive and long-term mode of

205

206

Case Study: Social Health

operation, may be an ideal technology approach for capturing and analyzing social health metrics.

9.3

Clinical Research Objective The clinical research aims for this project are as follows: •

•

To collect information about the social activities of older persons in their own homes. This information may be characterized in terms of visitors, phone calls, excursions, and so forth. It may be recorded by using a journal or by a sensor network. To discover whether levels of sociality can be modified by technological intervention. Can a system, informed by journal and/or sensor information, provide elders and caregivers with the stimulus needed to increase social interaction?

Both of these aims can be pursued through the provision of new technology-based services that support social contact between elders, their peers, their families, and caregivers. Thus, the potential exists to enhance the subjects’ quality of life, while at the same time creating new knowledge in this area. Four avenues for technological intervention are to be pursued: 1. 2. 3. 4.

9.4

Electronic journal recording of social activity by elders and caregivers; A display of sociality using an easy-to-understand visual metaphor, aimed at both elders and caregivers; A simple indicator of presence and availability, again for both elders and caregivers; Support for memory prompting as an element of caller ID with incoming phone calls.

Technology Objectives The clinical objectives outlined earlier translate into a progression of technology objectives. These include: • •

•

•

Identification of optimal WSN configuration to collect sociality data; Design and build of WSN infrastructure that will gather information about visits, phone calls, and other forms of social activity; Specification and implementation of software to convert WSN and journal information into appropriate input to the interventions listed above; Design, implement, and trial technological interventions for electronic journals, for sociality visualization, for enhanced telephone service, and for presence indication.

9.5 System Architecture

207

Your daughter is calling

PRESENCE SIGNALING

ELDER

Figure 9.1

9.5

CAREGIVER

System overview.

System Architecture The overall system architecture consists of the following elements: •

•

•

A home server receives data from sensors and analyzes it to inform applications such as the context ID system and to create visualizations of sociality. A collection of sensors that identify and record socially relevant activities. These include door, motion, pressure (chair), location tracking, and phone sensors. The sensors communicate with the home server via attached motes (radio plus microprocessor elements).

The home server runs a series of applications: •

•

• •

•

9.6

The sociality visualization enables the subject to visualize the evolution of social activity over time, and which is also accessible to the caregiver for similar reasons. Several forms of visualization are supported. The context ID application provides background and most recent conversation information about the caller when the phone rings. The subject uses the journaling application to record social activity. The presence signaling system lights a lamp in the caregiver’s house when the subject is available and vice versa. A Web application, accessed by the caregiver, allows the caregiver to access the visualization of the subject’s social activity online. It also supports an online journal, which the caregiver uses to record recent interactions and conversations.

Requirements Capture and User Modeling As usual, multiple sources of requirements information informed the system design. These included clinical requirements, usage modeling, and ethnography.

208

Case Study: Social Health

9.6.1

Clinical Requirements

The clinical requirements for the project were as follows: 1. 2. 3. 4.

To establish a baseline measure of sociality against which any intervention could be benchmarked; To introduce technology interventions and to measure the resulting sociality metrics, thus establishing the effectiveness of the interventions; To record objective data such as visits and phone calls and subjective data such as the level of satisfaction with a phone call; To involve both the subject (the elder) and the caregiver in the process.

The following metrics were used to capture sociality: •

•

•

Visits: By whom, for how long, satisfaction expressed by the elder and the caregiver; Excursions: With whom, for how long, satisfaction expressed by the elder and the caregiver; Phone conversations: Source and duration.

Satisfaction and other subjective information were to be recorded using a journaling application. 9.6.1.1

Social Index

An important element of the metrics was the use of a social index. This effectively weights the social value of an interaction by reflecting the relationship between the subject and the other person involved in the interaction. This means, for example, that an interaction with a daughter has a higher social value than a similar-duration interaction with a plumber. The social index value can be calculated for each day; days with many visits (e.g., Christmas) will have a high social index. In addition, the form or mode of interaction can also be weighted. Thus, for example, in-person visits have a higher social index value than telephone calls, which have a higher index than e-mail messages. SI i =

N

∑φ t j =1

j

j

is an expression of the social index, where:

SIi is the social index for person i; φj is the weighted mode of communication; tj is the duration; N is the number of visits. The use of such a social index means that a numerical value can be allocated to each person in the social circle, as well as to each day and to each social event. Trends can be identified, so that the building up of a new relationship can be numerically (and graphically) represented in a consistent and valid manner.

9.6 Requirements Capture and User Modeling

9.6.2

209

Usage Models

In order to see how the user could be expected to interact with the system, a day-in-the entified socially relevant events of visitors and telephone calls that could conceivably be detected by sensors and included in an overall model or profile for the subject. (Of course, many other activities can be detected, as discussed in previous chapters.) In addition, the modeling recognized that an important proportion of all social activity would take place outside of the house. In order to capture this information, a journal system would be needed, which would record the destination, the company kept, the purpose of the excursion, its duration, and the level of satisfaction of the subject with the excursion. 9.6.2.1

Visitor Usage Model

The following are the steps in the visitor usage model: •

•

•

Visitors are expected to arrive via the front door. The opening and closing of the front door will be noted. Visitors are expected to proceed into the hall and/or other areas of the house. The location of the visitor in each room of the house and the duration of the stay will be noted. Visitors are expected to leave via the front door. The opening and closing of the front door will be noted.

9.6.2.2

Telephone Usage Model

The following are the steps in the telephone usage model: • •

• • •

The phone ring will be noted. The caller ID will be noted; this will trigger the context ID intervention, described in Section 9.6.2.3. The phone pickup will be noted. The duration of call will be noted. Both the caller (caregiver) and the subject (elder) may comment on the phone call, using the journal system described later.

9.6.2.3

Context ID Usage Model

The following are the steps in the context ID usage model: • • • •

This is triggered by the detection of an incoming call. The context ID system receives the caller ID data from the sensor. The context ID system looks up the caller in its database. If the caller is a member of the social network, the context ID system retrieves the photograph, name, and relationship of the caller.

210

Case Study: Social Health

•

If recent interactions have been journal-recorded by the caller, these are retrieved and displayed.

9.6.2.4

Journaling Usage Model

The following are the steps a subject will take in the journaling usage model: •

•

•

The subject will record details of all social interactions (visits and phone calls) using online journal tool. A series of simple forms will be completed, including information about the interlocutor, duration, satisfaction level, and time. The user interface will be mouse-only, to keep it simple and fast (no keyboard).

The following are the steps a caregiver will take in the journaling usage model: •

•

•

9.6.3

The caregiver will record details of all contact with the elder using the online journal tool, which will include duration and time. The caregiver journal functionality will support the recording of topics of conversation and other textual data (keyboard and mouse). The caregiver journal data will inform the context ID functionality. Data to Be Collected

The data to be collected is all the data that is relevant to the creation of an accurate model of the social activity of the subject. This includes sensor data, as follows: • • • • • •

Front door arrival; Door opening and closing; Motion of one or more persons (e.g., subject plus visitor) within the house; Location of one or more persons within the house; Seat and couch occupancy; Phone ring, pick up, and put down.

The data to be collected also includes data actively provided by the subject and by the caregiver, primarily through the use of an online journal application. 9.6.4

Subject Interaction

Interaction with the user is through the applications running on the home server, plus the gentle prompt of the presence lamp. •

Visualization: This user interaction is delivered by the visualization application on the home server. It provides the user (subject or caregiver) with information about the present and past social activity of the subject. Several different visualization models are used, including graphics, text, and charts.

9.7 Technology Selection Criteria

•

•

•

9.6.5

211

Context ID: When the telephone rings, the phone sensor receives the caller ID information. This is forwarded to the home server, which identifies the caller in its database and displays a photograph of the caller, his or her name, and his or her relationship with the subject. If the caller has recorded details of the most recent call (including what was discussed), then this is displayed too. This enables the subject to be fully informed when answering the call. Journal: This is delivered by the journal application, which is accessed from the subject’s home server and from the caregiver’s computer. The subject interface is mouse-based and gathers information about social interactions; the caregiver interface collects similar information and also allows text entry. Presence lamp: When the caregiver triggers the presence lamp, the caregiver’s computer sends a message to the subject’s home server. This switches on a specific lamp in the home of the subject, indicating that the caregiver is available, should the subject wish to call. A similar arrangement lights a lamp in the caregiver’s home, when the subject triggers it (e.g., by sitting in a particular chair). Environment

The following are the requirements for the environment: • • •

• •

9.7

The environment is the home environment of the subject. The project conducted research in Las Vegas, Nevada, and Portland, Oregon. The Nevada houses are built from stucco, with steel beams; the Portland houses use brick and wood. Typical house sizes are of the order of 2,000 square feet. The project research takes place solely indoors.

Technology Selection Criteria The choice of technology is driven by the data that is to be collected and the impact on the end user. The solution must impact as little as possible on the end user; there is no intrusive actuation. The selection criteria are as follows. For sensor devices (door, seat, motion, doormat): • •

• •

The ability to detect the requisite information; The longer the sensing range, the less sensors are needed and the less intrusion is experienced; The ability to interface with the radio mote; The ability to differentiate between different weights (e.g., a subject and a pet) for the seat sensor.

For the wearable sensor (badge): •

The ability to identify radio sources and timestamp arrival of signals to allow for their use in location tracking;

212

Case Study: Social Health

• • • •

Lightweight; Unobtrusiveness; Durable; Low power demands.

For the radio mote: • • • •

•

Data processing ability, for preprocessing; Necessity to communicate effectively with the home server; Necessity to be battery powered for minimum intrusion; Necessity to be power-efficient, since the mote is deployed for long periods of time; The use of different motes in the badge and in the environmental sensors.

For software: • • • • • • •

9.8

Real-time analysis of the incoming data; Integrating and analyzing the data from the sensor and the journal; Several forms of visualization; Delivery of the journal application including network interface; Delivery of the context ID application; Supporting long-term data storage; Recognizing the presence lamp triggers and lighting lamps as appropriate.

Technology Selection The technologies selected for this project are described here. 9.8.1

Mote

The Crossbow MICA2 radio mote (Figure 9.2) was used to radio-enable sensors around the house. This mote can interface with up to eight sensors. Its Chipcon CC1000 radio has a range of up to 300m outdoors and about 30m indoors. 9.8.2

Door Sensors

The front door sensor takes the form of a pressure sensor in the doormat (Figure 9.3). The pressure sensor is triggered by somebody standing on it. The sensor is connected by wire to a mote, which handles the radio communications with the home server. 9.8.3

Motion Sensors

The X10 Powerhouse PIR motion sensor was chosen and modified to sense both light and motion by the project team. It was then interfaced with a MICA2 radio

9.8 Technology Selection

Figure 9.2

Crossbow MICA2 radio mote.

Figure 9.3

Doormat sensor.

213

mote for communications, using a multipurpose switch box. The entire assembly (Figure 9.4) was wall mounted using adhesive hook-and-loop strips, which allowed it to be removed and replaced easily for maintenance purposes. 9.8.4

Location Sensors

Infrared beacons and badges were used for location tracking. The badge consisted of the Crossbow Mote and board designed by the proactive health team at Intel, called the IR board. The IR board used a Microchip PIC12F675 that interpreted signals from Vishay TSOP31256 IR Module. The signals were sent through the PIC chip via the UART to the Mote Radio Processor Board. The badge system was powered by a 1,500-mAH Li-polymer battery custom made for the mote footprint. The Li-polymer battery was attached to a pin and post connector that allowed the badge to be recharged at night. The boards and battery were encased in a custom-designed ABS plastic. The enclosure for the badge had a small handle at the top to attach a lanyard or clip for wearing the device. A picture of the elder wearing the badge is seen in Figure 9.5.

214

Case Study: Social Health

Figure 9.4

Motion sensor and radio mote.

Figure 9.5

Elder wearing the badge.

The beacon consisted of an IR emitter tied to a PIC12F675. For timing a simple 555 timer was used. Each PIC chip was programmed with a unique serial address for a specified location in the home. The complete size of the system was 2 × 1 × 0.5 inches and was powered by an AC/DC converter. The beacons, each of which sends a unique infrared signal, are placed in each room of the house. Each visitor to the house wears a badge that sends a radio message whenever it detects an infrared bea-

9.8 Technology Selection

215

con. This information will inform the system who is in a particular room at any given time, allowing it to determine how long a visitor is present with the elder. Six badges were placed in each home: one for the elder and five others for the elder’s social network of friends and family. The elder was asked to wear the badge during the waking hours at home. Visitors were asked to wear a badge when they came over to visit the elder and dock the badge when they left. Docking the badge would disconnect the badge board from the battery, thereby turning off the badge. Every room in the home, except the bathroom, had one or more beacons installed on the walls (Figure 9.6). The beacons were directed such that the cone of the IR emitter would give the greatest coverage for that room. Where coverage was not complete, a second beacon was added to the system for complete room coverage. 9.8.5

Presence Lamp

The presence lamp system is a simple one. The caregiver carries a key fob or similar device, which he or she activates when he or she is at home and available. The key fob sends a message to the caregiver’s computer, which communicates with the subject’s home server. The home server then lights the appropriate lamp. At the subject’s home, the seat sensor in a chosen chair triggers a message to the home sensor, which informs the computer at the caregiver’s house. The caregiver’s computer then lights the appropriate lamp. Signaling uses infrared, similar to a TV remote. 9.8.6

Software

The software used in the project was developed specially for the project. It consisted of a database that stored all the incoming sensor and journal information, and the following applications:

Figure 9.6

Beacon on the walls of the elder’s home.

216

Case Study: Social Health

• • • •

The subject journal; The caregiver journal; The visualization application; The context ID application.

9.8.6.1

The Subject Journal

The subject journal is a simple online application (Figure 9.7) that enables the subject to note: • • •

Who the interlocutor was; The duration of the activity; How satisfying or enjoyable the social event was.

This information is stored on the home server, where it contributes to the social indices for the person and the day. 9.8.6.2

The Caregiver Journal

The caregiver journal enables the caregiver to record information about social events. The interface encourages the caregiver to provide some notes on the recent events; these notes may be reused by the context ID application to remind the subject of the circumstances of recent interactions.

Figure 9.7

Journaling application.

9.8 Technology Selection

9.8.6.3

217

The Visualization Application

The visualization application is the most ambitious and most research-valuable of the interventions in this project. It aims to inform both subject and caregiver on the state and the dynamics of the subject’s social circle. A number of different visualizations are provided. These are as follows. The Solar System

The model used is that of the solar system, with the subject in the central position, surrounded by the members of the social circle (see Figure 9.8). The closer a friend or relation is shown to the subject, the greater the degree of social contact recorded by the system between that caregiver and the subject. Faint trails in the display show the movement of caregivers within the solar system over time, reflecting the increasing or decreasing levels of interaction. The Line Graph

A line graph shows the level of social activity over time (see Figure 9.9). This is useful to highlight overall trends. Textual Summary

A simple textual statement gives some indication of the evolution of the social network (see Figure 9.10). The mode of operation of the visualization software was twofold: 1.

Figure 9.8

The subject can clearly see the development of relationships and contacts of each person in the social network and so can be prompted to reach out

Solar system visualization.

218

Case Study: Social Health

Figure 9.9

Line graph visualization.

Figure 9.10

2.

Textual summary visualization.

and contact members of the network who have recently been in contact or, indeed, who have recently drifted out of touch. The caregiver can easily see how socially active the subject is and also which members of the network (and which caregivers) are most active. This may prompt the caregiver to contact the subject in order to ensure that every caregiver is contributing his or her share of the care.

9.9 Deployment

9.8.6.4

219

The Context ID Application

The context ID application (Figure 9.11) provides context information about a caller when the telephone rings. The caller ID is used to retrieve a record of a name, a photograph, and a relationship. If the caller/caregiver has used the journal application, the context ID application also shows what was last discussed between the subject and the caregiver.

9.9

Deployment The deployment of the project solution took place in three homes in Nevada and three homes in Oregon. During the deployment, several lessons were learned. These are outlined here. An example deployment schematic is shown in Figure 9.12. 9.9.1

Radio Enclosures

The mobility/light sensors and their attached radio motes were installed successfully; the tested range of the radios was 45m—easily covering the whole house. However, the enclosures used were black in color and did not integrate well with the décor of several homes (see Figure 9.13). Sensitive to user feedback and subject happiness, the project team replaced the device with an identical unit, but this time with a white enclosure (see Figure 9.14). This was considered more acceptable by the subjects. However, on retesting the radio, it was found that the range had fallen from 45m to 2m. This made the radio solution unviable and threatened the entire project. Upon investigation using electron microscopy and energy dispersive spectroscopy, it was discovered that the white enclosures contained a small percentage of titanium. This metallic enclosure acted as a Faraday cage around the radio mote, effectively blocking its RF signal. Subsequent installations have used a gray enclosure, which is less intrusive than the black one and more radio-friendly than the white one. Full details of this lesson are described in Chapter 4.

Figure 9.11

Context ID.

220

Case Study: Social Health

Office motion

N

motion

bed

Living

Bath Master lamp

motion

chair

Laundry motion

MBath

motion

Kitchen

Garage

mat motion

Dining

Figure 9.12

Deployment schematic.

Figure 9.13

Black enclosure.

9.9.2 9.9.2.1

Infrared Location Tracking Issues Fluorescent Lights

As described in Section 9.8.4, the location tracking technology used in this project relied on the use of infrared beacons and infrared sensors connected to motes. How-

9.9 Deployment

221

Figure 9.14

White enclosure.

ever, it was found that common fluorescent light sources emit a low-frequency (60–90-Hz) jitter, had a significant impact on the IR communications. 9.9.2.2

Protocol Issues

At the time of the project there was no acknowledge-receive protocol for the mote system. To ensure that the RF messages were received, each message was numbered and sent out three times. At the beginning of the study, each home was surveyed for RF signaling distances and interference. When RF interference was encountered, a relay was added to the system to increase the range of the mote network. Thus, it is possible for the computer receiving the mote messages to hear the message up to nine times. An improved protocol with acknowledge-receive was subsequently put in place. Overall, infrared was not found to be an ideal tool for location tracking. In this project, it was necessary to back up the IR technology with motion sensors and to verify that all motion sensor readings had corresponding IR readings. As outlined in Chapter 8, the use of Bluetooth radios for in-home location determination is quite successful; as described in Chapter 10, new ways to achieve this valuable goal continue to emerge. 9.9.3

Building Materials

As noted earlier, this project deployed in two locations: Oregon and Nevada. While brick and timber housing is common in Oregon, the Southwestern United States tend to use metal mesh and concrete stucco as the primary building material. This reflects the high cost of timber in the desert Southwest and also the prevalence of termite infestation.

222

Case Study: Social Health

Systems that deployed without problem in Oregon failed to do so in Nevada; radio communication within and beyond houses was significantly curtailed, with a massive loss of radio range. Investigation found that the steel mesh used in house construction acted as a Faraday cage, blocking radio signals at walls. The steel beams used for structural purposes in Nevada also caused problems. The Southwest is also more prone to thunderstorms and lightning storms than most other parts of the United States. As a result, houses and apartments tend to be grounded to the earth, which further increases their impermeability to radio waves. 9.9.4

Pets

Pets caused some difficulty. Pets are typically not included in laboratory or friendly testing, but add a major new variable during a real-world rollout. Motion sensors can be triggered by pets; seat, couch, and bed sensors can be fooled by large dogs; and pets cannot reliably be instructed not to touch sensors or other technology elements. The team found that pressure sensors with adjustable thresholds for sensitivity could be configured to ignore pets, though the possibility remains that a child might pass unnoticed by the sensors if they are set to ignore a large dog. Similarly, motion sensors based on passive infrared can be configured to ignore cats and other small pets; however, similar issues with large dogs and small children remain. No amount of configuration will protect against all eventualities. During one deployment, the pet dog found and ate the IR badge of the subject, causing it to cease to function. 9.9.5

Every House Is Different

During the deployment phase, each house or apartment had to be measured and have radio friendliness assessed. Ranges for sensors had to be verified, signal quality had to be measured, sources of interference had to be identified and neutralized, and so forth. Quite apart from the built environment, the priorities and tastes of the subjects also had an important impact; décor and tidiness are very important to some subjects and must be respected (this is described in more detail in Chapter 6).

9.10

Results The final results of the research study are not immediately relevant here; the area of interest from the engineering perspective is primarily in the specification, design, and implementation phases. However, the following notes may be instructive: •

•

A major issue for the project was the fact that much socialization takes place out of the home. Such socialization cannot be tracked by technology deployed in the home; as a result, the home-based solution provided only a partial picture of the subject’s social activity. Sensors can indeed be used to successfully detect and measure social activity in the home. There was a strong correlation between the data captured by sen-

9.11 Conclusion

•

•

9.11

223

sors and those recorded by subjects in their online journals. The technology did not miss any socialization events that occurred in its area of coverage. The deployment of the technology did have a real impact on the social activity of the subjects. The deployment was broken down into two periods: •

A baseline period, during which the social activity of the subjects was recorded and the journal could be accessed, but no intervention was attempted;

•

An intervention period during which the visualization and context ID solution were active.

The results showed that levels of social activity increased measurably during the intervention period. This is a positive indication of the value of technology interventions in social health; wider studies with more cohorts will be worthwhile in the future.

Conclusion This final case study looked at an interesting research project measuring the difficult-to-quantify values of social health. A mathematical model for sociality was drawn up, and this social index was used as a metric throughout the project. Novel ideas for stimulating the social activity of the subject and of encouraging caregivers to engage with the subject were discovered, designed, and implemented. The deployment of the data gathering sensor network and of the technology interventions led to a number of key lessons being learned. These included the fact that every house is different, and a single one-size-fits-all solution is elusive, and that sensor technology and radio communications remain important sources of failure, needing great care from the engineer.

References [1] [2]

[3]

[4]

Dishman, E., “Inventing Wellness Systems for Aging in Place,” IEEE Computer, May 2004. Lamming, M., and D. Bohm, “SPEC’s:Another Approach to Human Context and Activity Sensing Research, Using Tiny Peer-to-Peer wireless Computers,” UbiComp 2003: Proceedings of 5th International Conference on Ubiquitous Computing, Seattle, WA, October 2003. Needham, B., and T. Dishongh, “A State of the Art Assessment of Activity Sensors Showing a Need for Nano-Technology,” First Annual Workshop on Packaging for Bio and Nanotechnology, Atlanta, GA., March 2004. Haigh, K. Z., et al., The Independent Life-Style Assistant TM (I.L.S.A.): Lessons Learned, Honeywell Laboratories Technical Report number ACS-P03-023, December 2003.

224

Case Study: Social Health

Select Bibliography Cook, D., and S. Das, Smart Environments, New York: John Wiley and Sons, 2005. Crossbow Technologies, MPR/MIB User’s Manual, Document 7430-0021-06, Rev A., August 2004.

CHAPTER 10

Future of Wireless Sensor Networks for Healthcare 10.1

Introduction An examination of demographic trends shows that the world’s population is aging rapidly. An aging global population will generate a greater demand for novel technologies, including sensor-based solutions, to support a range of healthcare applications in the future. Our research and observations related to current sensor-based healthcare applications suggests that the future does not lie in wearable sensors, such as ECG monitors, pulse oximeters, or even simple tracking watches. The effectiveness of such devices depends on a high level of user compliance. Over the course of numerous trials of sensing technology, we have seen that compliance is a major problem, creating false positives and erroneous signals within the sensed data when participants fail to wear the sensing device, do not wear it properly, or forget to charge the device. In this chapter, we explore the use of noncontact sensing technology as a better alternative for the future of healthcare applications. We describe applications ranging from sensitive clocking on silicon to the use of Doppler effect radio frequency radar to detect heartbeat and blood pressure. Some industrial technology trends are also discussed, such as the use of 802.11 as a low-power radio stack for WSNs and the reallocation of the 700-MHz (UHF) spectrum in June 2009, enabling the pathway for personalized ubiquitous displays in the home.

10.2

Noncontact Sensing: The Burnfoot Project In the Burnfoot project, my colleagues and I explored a noncontact sensor technology based on the reciprocal counting of clock signals being sent down thermal-mechanical stressed microstriped lines. The Burnfoot technology is based upon the principle that as interconnects are heated, or through mechanical loading, they expand through the mechanism of Hooke’s Law [1]. In launching the Burnfoot project, we asked: What if there were a method to utilize this principle in an environment such as the home or workplace, to capture human sensory signals, such as heartbeat and respiration, using such a sensing mechanism? The components of the Burnfoot sensing system are shown in Figure 10.1. The main concept underlying the technology is that material under stress (the dashed line in Figure 10.1) in a sensitive sampling circuit enables a mechanism for the mea-

225

226

Future of Wireless Sensor Networks for Healthcare

Post stressed output signal

Input signal Material under stress

Sensitive sampling circuit

Display Figure 10.1

Processor

Components of the Burnfoot sensing system.

surement of vital signs without the need for the human to wear any sensor device. This section describes the circuitry of the sensitive sampling system we designed and how it links to the interconnect wire to enable the extraction of human signals such as heartbeat and respiration. One of the primary considerations in this circuit design was the creation of a very sensitive mechanism that would allow the data coming from the stressed material to be analyzed. In the same way that strain gauges use changes in resistance to measure thermal-mechanical loading, the Burnfoot device would use changes in resistance as the interconnect expands to measure the time it takes for signals to run through a given trace. As illustrated in Figure 10.2, a reference signal is input to the Burnfoot sensor down an unloaded trace of a known length. Simultaneously, a signal is transmitted through the stressed path shown in the figure. If the two paths are equivalent in length in the unstressed state but the stressed trace has expanded due to the loading, then we would expect to see an inherent delay in signal transmission due to this expansion. Furthermore, if the sensitive circuit were designed to be able to discern the differences in the time of flight of the two signals, then using digital signal processing (discussed in Section 10.3), a relationship between the heat applied to the interconnect could be traced back to the thermal-mechanical loading. If the dynamic range

10.2 Noncontact Sensing: The Burnfoot Project

227

Input signal

Material under stress

Figure 10.2

Sensitive circuit output

Stressed output

Overview of the sensor system operation.

of the device were sufficiently high, with a large signal-to-noise ratio, then human physiological signals could be derived from the device, as long as the electronic circuit is sensitive enough to pick up the change in signal transmission time. There are numerous methods for measuring differences in signal transmission times. Frequency counting is one such technique, but it has precision inadequacies at low frequencies. Period or reciprocal counting is a better method to handle the resolution issue due to a constant resolution independent of frequency. Reciprocal counting also allows the control of the gating (or sampling) of the signal. Therefore, this technique was selected for use in the Burnfoot technology. In Horowitz and Hill [2], a basic circuit was presented for time-interval measurement. This circuit has been modified for the Burnfoot system shown in Figure 10.2. A clock signal is used as the input signal, as shown in Figure 10.3, which illustrates the circuit for the sensitive measurement of timing differences between CLOCK_PULSE1 and CLOCK_PULSE2, provided that CLOCK_PULSE1 occurs first. A dashed box surrounds the two NAND gates, which are configured as an SR latch. While the system shown in Figure 10.2 has one input supplying both signal paths, Figure 10.3 uses two separate sources to aid in visualizing the operation of the system. Figure 10.4 shows the system waveform outputs from a segment of a simulation between 20 ms and 50 ms. CLOCK_PULSE1 and CLOCK_PULSE2 generate start and stop pulses to set and reset the inputs of the SR Latch (for further details on SR Clock_pulse 1

Inverter 2

Start

Nand 2_1 Inv_start

Latch_D

DLatch 1 DLatch Q D CLK

Nand 2_2 Clock_pulse 2 Stop

Inverter 3 Inv_stop

Clock 1

Figure 10.3

Basic sampling circuit.

QN R

Nand 2_3 Latch_Q

Output

228

Future of Wireless Sensor Networks for Healthcare

Waveforms generated by basic sampling circuit Figure 10.4

(a–c) Waveforms generated by basic sampling circuit.

latch operation, see [3]). This provides a pulse whose length corresponds to the delay between the leading edge of both pulses. The pulse is then fed into the d-input of a d-latch. The d-latch accesses its d-input on every rising clock edge and transfers the input value to its output terminal (Q). The d-latch prevents timing irregularities, such as runt pulses, and synchronizes the system. The d-latch output (latch-q) provides one input to an AND gate, with the other input being connected to the d-latch clock input, CLOCK1. This provides a series of pulses, corresponding to the frequency of CLOCK1, which would then be counted by a frequency counter or microprocessor, as illustrated in Figure 10.1. In Figure 10.4, three simulations were completed where the CLOCK1 input was varied across each simulation, 500 Hz, 1 kHz, and 2.5 kHz, respectively. The output signals (output) from the three circuit simulations showed that greater accuracy could be achieved by setting the CLOCK1 input to a higher value. While the previous simulations proved adequate thus far in the development of Burnfoot, alternative scenarios were investigated that evolved the sampling circuit, adding greater sensitivity. One such scenario is presented in Figure 10.5, where the delay between pulses, t1, was relatively small and the stop pulse occurred during the start pulse. Instead of the number of pulses representing t1, it can be seen that the sensor output represented the length of the start pulse, as shown by t2. This is due to a fundamental rule in sequential logic circuits that dictates that both inputs of the SR latch cannot simultaneously be high; this is a forbidden state [3]. A delay was initially inserted in the stop pulse interconnect to ensure that the stop pulse could not take place until after the start pulse had switched off. This is illustrated in Figure 10.6, which shows that the high-precision sensor circuit has further evolved from that of Figure 10.2. In Figure 10.6 the same source,

10.2 Noncontact Sensing: The Burnfoot Project

229 Start Stop Latch_d Latch_clk Latch_q Output

0.0m

41.0m

42.0m

43.0m

44.0m

46.0m

45.0m

47.0m

48.0m

49.0m

50.0m

51.0m

52.0m

53.0m

Time(s)

Figure 10.5

Effect of reducing the time between pulses, that is, reducing the delay (Z).

CLOCK_PULSE1, supplies both the start and stop inputs of the SR latch. The stop signal is the first delay (as indicated by the dashed-line box). There is an additional delay related to the amount that the Z-sensor trace line expands or contracts due to the change in temperature or stress. The output pulses (OUTPUT) of the d-latch would then be fed into a microprocessor. Knowing the CLOCK_PULSE1 length (i.e., start length) and the number of pulses it comprises (which is dependent upon the clock signal CLOCK1), we can compute the number of pulses in the time delay of the Z-block by subtracting the expected from the overall CLOCK-PULSE1. The microprocessor would then calculate the delay using predefined instructions. It was possible to reduce system components by removing the delay component as well as the inverter at the stop terminal. The inverter connecting the CLOCK1 signal to the CLK port of the d-latch was also removed to switch the latch_q on earlier in the latch_d input signal. In all the scenarios described thus far, the input START/STOP signals were single pulses made using pulse generators. While a pulse generator, as illustrated in Figure 10.6, made by adjusting the mark-to-space duty cycle, is simulated in the circuit design, another interesting simulation is to check the sensitivity of the architecture using a 50:50 (duty cycle) clock input, as illustrated in Figure 10.7.

CLOCK_PULSE 1 START

HAND2_1

INY_START

DELAY

NAND2_2OUT

LATCH_D

DLATCH1 LATCH_Q D Q CLK

QN A

DELAY_START

Z-COMPONENT Z-OUT

NAND2_2 INV_STOP

Z-sensor

Figure 10.6

Sampling circuit from a single clock pulse input.

HAND2_3 OUTPUT

230

Future of Wireless Sensor Networks for Healthcare

Figure 10.7

Insertion of clock frequency supply to reduced sampling circuit.

Figure 10.8 plots the results of the simulation of Figure 10.7 and shows the delay between the CLOCK_INPUT, START (2 kHz) and the same two signals after passing through the Z-sensor (Z-OUT). The main difference in Figure 10.8 is that the sampling clock frequency is increased in Figure 10.8(b), providing greater sensitivity. This shows that the circuit operates as desired. 10.2.1

Incorporation of Derivation Findings into Burnfoot Sensor Simulations

We investigated a mathematical derivation of a change of displacement of 10 nm that would correspond to a signal delay of 1.8 ns in a microstrip line. In the process, we proved there is a Poisson effect, whereby the change in the width of the line is small relative to the change in length; thus, changes in width have little impact on the sensitivity of the circuit. We applied this knowledge, combined with previous modifications made to the V components of the sensor, to create the final circuit design. The input signal (START) was applied with a frequency of 50 kHz and has two interconnect routes: the reference line, which goes into an inverter, which in turn

(a)

(b)

Figure 10.8

(a, b) Sampling circuit outputs.

10.2 Noncontact Sensing: The Burnfoot Project

Figure 10.9

231

Simulation circuit.

enters the SR latch, and the sensor line, which will be stressed. The effect of the 10-nm displacement can be seen in the timing diagrams of Figure 10.10(b, c), which illustrates a 500-μs simulation of Figure 10.9. In Figure 10.9, the start pulse is the direct (reference) 50-kHz signal. The z-out signal is the delayed signal after being disturbed by the sensor. This delay is so small that it cannot be seen in Figure 10.10. The output signals must be highly focused (zoomed) to view the delay between the signals, as in Figure 10.11. In the circuit shown in Figure 10.10, rather than calculating the delay directly by examining the pulses that represent the delay, we focused on the rising edge of the start pulse and falling edge of the z-out signal and the delay calculation being carried out by the microprocessor. This is accomplished by: Z Delay = TimeOverall − Time Known

(10.1)

where ZDelay is the delay caused from the sensor line, TimeOverall is the total number of output pulses (i.e., caused by the whole pulse, from the beginning of the start pulse to the end of the z-out pulse). The overall time difference is calculated by multiplying the number of pulses by the period of the clock signal. For example, for a 1-GHz clock (shown in Figure 10.11), the overall time would be TimeOverall = N Pulses * 1 × 10 −9

(10.2)

TimeKnown is the known length of the start pulses. 10.2.2

Potential Applications

Circuit simulations show that the Burnfoot technology is generic, adaptable, and capable of measuring any physical phenomena with very high precision. The potential of the Burnfoot sensor to work in a noncontact, nonintrusive manner opens the door to unlimited opportunities for capturing many biological signals for WSN healthcare applications. Imagine the possibilities: noninvasive core temperature measurements with an accuracy of ±10−4°F, noncontact monitoring of vital signs

232

Future of Wireless Sensor Networks for Healthcare

Figure 10.10

(a, b) Signal outputs of a zoomed view of Figure 10.2.

Figure 10.11

(a, b) Zoomed view of Figure 10.10.

from beneath a mattress, or household bathroom scales that can measure heart rate from the feet, to name just a few potential applications. In the Burnfoot project, we explored a potential bathroom scale application (Figure 10.12). If used in a common scale, the Burnfoot sensor has such large bandwidth and high resolution that we were able to measure not only a person’s weight but the minute displacement caused by the person’s beating heart. In our experi-

10.2 Noncontact Sensing: The Burnfoot Project

233 −3 1.4 x 10

[Time domain]

[FFT] Respiration (0.3Hz)

1.2 1.0 0.8 0.6 Heart beats (1.3Hz)

0.4 0.2 0

5

10 Time[sec]

15

20

(a)

Figure 10.12

00

0.5

1

1.5

2

2.5

3

Frequency [Hz] (b)

Weight scale Burnfoot application.

ment, the subject’s weight remained constant (roughly 180 pounds), but the beating of his heart caused a continual change in his center of gravity. This change was significant enough to change the propagation time of the wavelength transmitted from the subject’s feet as he stood on the scale. We summed the stream of time delays from (10.1), which are proportional to the load on the sensed line. The time delays were calibrated to the actual loaded displacement for the subject’s weight. A fast Fourier transform (FFT) was used to process subsequent signals after the initial loading on the scale. Using digital signaling processing techniques, we then relied on ballistocardiography, which measures the effect of heart and lung activity by directly measuring the acceleration of the blood through mechanical means. From this measurement, it was possible to extract heartbeat and respiration. 10.2.3

Burnfoot Validation

With circuit simulations and a sample application completed, a two-layer PCB was designed with an input clock frequency of 500 MHz from the Vectron VS700 and a sampling clock of 8 MHz using a Maxim 7375 chip. The delay latches and the SR latch were designed using a Dual FF and Quad NAND gate. Sense and reference traces were drawn on opposite sides of the layout such that the line lengths were the same and impedance matched. The output line in Figure 10.9 was attached to a digital signal analyzer to read the time delays. The layout is illustrated in Figure 10.13. For preliminary validation, the reference line was kept at a constant temperature while the sense line was gradually heated. As heat was applied, thermal couples attached to both the reference and heated sides of the PCB allowed the measurement of the thermal difference with respect to the increase in time delays from the sensor. The secondary test was the mechanical loading of the sensed side of the board while the reference side was fixed in a vice. By connecting the sensed side to a known mechanical vibration, the time delays coming from the sensor were plotted to a real time clock, thereby capturing the associated signal.

234

Future of Wireless Sensor Networks for Healthcare

Figure 10.13

Burnfoot design in PCB.

The circuit and methodology for Burnfoot shown in this chapter are based on a generic technology platform that enables precise measurements to be calculated for a fraction of what it would cost using other measurement techniques. For instance, other noncontact sensing techniques for heartbeat and respiration include the use of strain gauges in chairs and beds, sensitive pressure mats in beds, and the use of aluminum nitrite sputtered with carbon and aluminum to make a sensor in a chair that picks up pressure waves in the chest while the patient is seated in the chair. All of these techniques are more costly and less reliable than measurements made using the Burnfoot technology. Even though our focus has been on healthcare applications, the technology described in this chapter is not limited to one or two industries. The Burnfoot technology could be used to develop applications for the automotive, aerospace, aviation, communications, security, gas, and oil exploration sectors, among others. For the first time, one sensor platform enables the measurement of any physical parameter.

10.3

Using Radio Frequency for the Biosignals Data Collection In the late 1970s, the U.S. Army discovered that it was possible to develop clothing that would cloak infrared signals. This made the forward looking infrared (FLIR) imaging devices used by the U.S. Army and the Soviet Union ineffective at detecting enemy soldiers in a field. As a result of this technology development, the U.S. government published a request for proposals from universities and government labs to construct a noncamera or IR method to detect human presence. One solution purposed by Georgia Tech was the use of Doppler radar to detect the heartbeat and respiration of a person through a wall. The Doppler radar device proposed by Georgia Tech became a patented device that is sold to the U.S. Army and law enforcement agencies throughout the country. Later, Lucent Technologies discovered the same effect as an artifact of cell phone technology.

10.4 Movement to Standardized Radios for WSN

235

This technology solution could be targeted at home monitoring for patients with sleep apnea and coronary heart failure. As in our bathroom scale application, the solution utilizes the ballistocardiogram technique, which enables the detection of heartbeat and blood pressure information from signal processing on the interference of low-power radio waves. The interference occurs due to the Doppler effect (described in the following section) and is a common artifact of a transceiver within specific bandwidths and frequency ranges. While this technology holds the potential for the noncontact gathering of vital signs, there are some issues and limitations that must be addressed. For instance, the signal must be directed parallel to the subject’s chest to have proper RF penetration and reflection. Another issue is interference in the ISM band. Yet another issue is the problem of how to detect the presence of multiple people and differentiate which signals are coming from each person. 10.3.1

Leveraging the Doppler Effect

The Doppler effect is a phenomenon observed whenever the source of waves is moving with respect to an observer. The Doppler effect can be described as the effect produced by a moving source of waves in which there is a perceived increase in frequency as the wave approaches the observer and a perceived decrease in frequency as the wave retreats from the observer. The Doppler effect can be observed to occur with all types of waves—most notably water, sound, radio, and light waves. In leveraging the Doppler effect to measure heartbeat and blood pressure, one challenge is that as a person moves, the signal strength of the compressed radio waves will vary, with the highest signal strength present when the RF emitter is orthogonal to the subject. Hence, to use a noncontact, Doppler-based system to measure heartbeat and blood pressure, the system would have to recalibrate continuously as the human moved in the field of concern near the emitter. Methods of extracting heartbeat, respiration, and blood pressure from a signal noise in other physical detection devices are well known, but the calibration of the signal could be a challenge. The wave radiates orthogonal to the antenna, leaving dead zones at the ends of the antenna where the device is least effective. This dead zone effect is increased as the emission power is reduced, which is an issue with low-power radios. One way to reduce the dead zone effect is the use of an omnidirectional antenna. This is an improvement over a dipole antenna, but it is not a perfect solution. Dead zones occur in all antennas, regardless of the design, and RF shadowing and low emissions make this method of noncontact sensing difficult to implement. On the other hand, the technology would be highly suitable if the incident radio waves are perpendicular to the heart, as opposed to being oblique, ensuring full signal quality and contact.

10.4

Movement to Standardized Radios for WSN Thus far in this chapter, we have focused on noncontact sensing as a technology of the future. In the near future, we can also expect to see 802.11 single-chip radio solutions, which show promise for low-power applications, including potential healthcare applications. In particular, 802.11n radio stacks are poised to become

236

Future of Wireless Sensor Networks for Healthcare

the mainstream single-chip solution at 90 nm. These single-chip solutions use less silicon and less power compared with previous dual-chip solutions. Many of the new radios being rolled out from GainSpan and G2 Microsystems also include embedded processors integrated in a single chip, offering the possibility of including code and data storage on the single-chip solution. These devices are expected to dominate the market in the near future, as they will work with existing infrastructure such as Wi-Fi access points and existing personal computers.

10.5

Ubiquitous Displays With the Federal Communications Commission (FCC) scheduled to roll out highdefinition digital television standards in 2009, various segments of the spectrum once used for ultra high frequency (UHF) television channels have become available for other uses. Numerous articles in technical magazines have described how the FCC is reallocating spectrum licenses and how major companies such as Google and Microsoft are acquiring the licenses by successfully demonstrating new technologies that make use of UHF frequencies to transmit information and specific channels of news, TV, and events localized to a 50-mile radius of TV towers [4–13]. These ubiquitous displays also could be used to transmit health and wellness data to targeted audiences, including information about environmental changes that may impact one’s health, such as pollution levels and pollen counts.

10.6

Conclusion The future of any field is difficult to predict with accuracy, but with the global aging of the population, it is reasonable to infer that there will be a growing demand for healthcare services and a corresponding need for low-cost technology to assist in the delivery of those services. Technology that leverages wireless sensor networks has the potential to assist in meeting the growing healthcare demands of the future—for instance, by making medical equipment easier to use, enabling home-based assistive care, and delivering and displaying health and wellness information through ubiquitous, low-power displays in the home.

References [1] [2] [3] [4] [5] [6] [7] [8] [9]

Young, W., and R. Budynas, “Roark’s Formulas for Stress and Strain,” 2002. Horowitz and Hill, “The Art of Electronics,” 1989. Warnes, J., “Analogue and Digital Electronics,” Chapter 10, 1998. http://www.techspot.com/news/28704. http://www.digitimes.com/bits_chips/a20080121PD213.html. http://www.techspot.com/news/28704-80211n-vendors-prepared-to-drop-prices.html. http://arstechnica.com/news.ars/post/20070720-google-announces-intent-to-bid-on-700m hz-spectrum-auction-if.html. http://www.technewsworld.com/rsstory/61262.html. http://www.reuters.com/article/businessNews/idUSN1447941620080114.

10.6 Conclusion [10] [11] [12] [13]

http://gigaom.com/2007/03/14/700mhz-explained/. http://www.mactech.com/news/?p=1010089. http://www.wetmachine.com/item/741. http://www.bbwexchange.com/pubs/2007/12/17/page1409-1358904.asp.

237

Index A Activity beacon, 165, 166, 180–82 description, 180 enclosure, 182 enclosure illustration, 183 general usage and requirements, 180–81 requirements, 181–82 technology features, 167 usage, 180 See also Medication reminders Actuators inference engine, 187 interfaces, 16 selecting, 10 WSN module, 14 Adaptive frequency hoping (AFH), 28 Ad hoc sensor networks, 15 ADL applications, 104–5 Aggregators, 68 communications interface, 83 defined, 10 selection criteria, 134 specifying/building, 10 µAMPS, 24 Ant, 21 Antennas, 16 array, 32, 33 designs, 29–33 dipole, 32–33 monopole, 32, 33 patch, 32, 33 types of, 32 AquisGrain, 21 Architectural models, 65–67 cost, 65 energy efficiency, 66 fault tolerance, 66 location, 66 long-term user exposure, 66 medical regulatory, 66 privacy and security, 67 routing, 66 scalability, 65–66 wireless regulatory, 66

Architecture generalized WSN, 64–65 network, 14–16 WSN device, 17 Array antennas, 33 At-home healthcare, 5, 6–7 Auditory-portable reminder, 155, 159 AWAIRS 1, 21

B Backward chaining, 98, 103 Bayesian and Markov models, 100–105 ADL applications, 104–5 basis, 101 Bayesian networks, 101, 102 as conditional probabilities models, 101 defined, 100 Markov random field models, 101–2 See also Inference engines Bayesian networks, 101, 102 defined, 102 ECG monitoring application, 103 illustrated, 102 Bayes’ theorem, 101 BEAN, 21 Bed sensors, 166, 183–84 Bench testing, 109–10 BioMOBIUS, 147 Biosensors, 35–36 Bit error rate (BER), 193, 195 Bluetooth, 28 RSSI/BER on, 193–94 testing, 89–93 Body area networks (BANs), 6 Body-worn sensors, 141–43 batteries, 141 design choice, 143 leg, 142 requirements, 141–42 BSN, 21 BTNode, 21 Burnfoot project, 225–34 bathroom scale application, 232–33 circuit design, 226 components, 225–26

239

240

Burnfoot project (continued) defined, 225 derivation findings in, 230–31 design in PCB, 234 frequency counting, 227 potential applications, 231–33 sampling circuit, 227, 228, 229 sensor system operation, 227 time delays, 233 validation, 233–34 weight-scale, 233

C Chains, 95 Channel quality driven data rate (CQDDR), 28 Chemical sensors, 35 CITNode, 21 Clinical deployments, 125–47 clinical parameters, 128–30 conclusion, 147 data analysis and reporting, 130–32 data collection and storage, 130 environmental issues, 133 ethnography, 132 PDRD, 136–45 problem statement, 125 requirements, 127–32 research objective, 126–27 subject interaction, 132 system layout, 137 system validation, 145–46 technology objective, 126–27 technology selection, 134–36 technology selection criteria, 133–34 usage modeling, 132 user definitions and permissions, 127–28 Clinical requirements document (CRD), 1 acquisition rate, 129 data, 46 defined, 45 environment, 47–48 format definitions, 131 general subject data, 128–29 information reporting, 46–47 kinematic data definitions, 129 medical history, 128–29 real-time data display, 131 sample contents, 48–49 subject interaction, 47 topics, 46 user role definitions, 127

Index

user system interactions role definitions, 128 Clinical research objective, 126–27, 206 Collaborative design, medication reminders, 160–62 Consistency enforcers, 96 Context aware medication prompting (CAMP) system, 174 reasoning system, 190–93 RSSI/BER analysis, 194 Context ID application, 219 Context ID usage model, 209–10 Cost, 65 COTS Dust Family, 21 Crossbow Mote, 213

D Decision models, 95 Demographic context, 2–5 Deployment, 107–23 building materials, 120–22 choice of radio, 117–20 clinical, 125–47 field experience, 117–23 fluorescent lamps and infrared, 123 human frailty, 123 installation, 114–15, 120 maintenance, 115–16 planning, 107–8, 117 preinstall, 113–14 social health, 219–22 stages, 107 teardown, 116–17 testing, 108–13, 122 Descriptive models, 95 Dipole antennas, 32 Documentation, 113 Door sensors, 166, 185, 212 Doppler effect, 235 DOT, 21 DSY25, 21 Dynamic Bayesian networks (DBNs), 191, 192

E Electromagnetic compatibility (EMC), 112 Embedded processors, 170 Ember, 21 End user modeling, 45, 49–52 Energy efficiency, 66 EnOcean, 21 Environment clinical deployments, 133 CRD, 47–48

Index

friendly test, 111 social health, 211 WSN use, 13 Ethical review, 111–12 Ethnography, 45, 49–52 clinical deployments, 132 conclusion, 51 defined, 49 for design, 50–51 field experience, 60 medication reminders, 153–54 modeling, 50–51 optimum results, 52 participant observation, 50 EyesIFX 1/2, 21

F Failure modes and effects analysis (FMEA), 2, 45, 55–59 defined, 55 examples, 56–59 risk assessment, 55 Fault tolerance, 66 Field experience ADL applications, 104–5 Bluetooth testing, 89–93 deployment, 117–23 furniture cruising, 60 radio enclosures, 85–89 FireFly, 21 Firmware, 76–82 communications standards, 81–82 real-time operating system (RTOS), 76 scheduler, 76 TinyOS, 76–81 See also Technology Fleck, 21 Fluorescent lamps, 123 Football capture, 134 mapping technology, 135–36 Football sensor, 137–41 design choice, 140 requirements, 137–40 Taxel map, 140, 141 Forward chaining, 98 Forward looking infrared (FLIR), 234 Fraunhofer region, 30 Frequency counting, 227 Frequency hopping spread spectrum (FHSS), 28 Fresnel region, 30

241

Friendly environment test, 111 Furniture cruising, 60

G GNOMES, 21

H Half-wave dipoles, 32 Hardware clinical research, 71–72 custom solution, 72 data integrity, 70 design review, 75 documentation, 73–75 existing solution, 72 installation, 114–15 PDRD, 73–75 performance, 69 power variation tolerance, 71 prototyping, 75 quality of service, 69 range, 70 security, 70 selection criteria, 68–71 standards compliance, 71 two-chip versus single-chip, 72–73 wireless coexistence, 69 See also Technology Healthcare architecting WSN solutions for, 63–67 at-home, 5, 6–7 delivery costs, 6 WSN, 9–11 Health SPOT, 164–65, 174–80 device construction, 195–200 embedded software description, 177–80 enclosure description, 177 location stack, 179, 195–96 location stack pseudocode, 178, 198 power requirements design, 177 purpose, 174–76 radio, 176 SPOT watch modification, 193 stack pseudocode prompting, 179–80 technology features, 167 watch, 176 watch buttons, 177 watch charging, 178 See also Medication reminders Human frailty, 123

I IBadge, 21

242

IEEE 802.11 (WiFi), 28 IEEE 802.15.4, 26–27 IEEE 802.15.4/ZigBee, 27 iMedTracker, 164, 166–74 Bluetooth message, 190 cell cross section, 168 embedded processor, 170 enclosure description, 166–69 enclosure illustration, 169 general usage and requirements, 168 LED lighting illustration, 169 matrix LCD, 172 power requirements design, 173–74 radio, 170–71 RTC and Watch Dog, 171 sensors, 172–73 technology features, 167 See also Medication reminders iMote, 1–2, 20–22 Industrial, scientific, and medical (ISM) band, 170 Inference engine, medication reminder, 185–90 activities, 185–86 activities affecting adherence, 186 activities affecting prompt response, 186 detection effects, 186 inference types, 187–90 non-detected effects, 186–87 sensors and actuators, 187 Inference engines Bayesian and Markov models, 100–105 categories of, 96–97 consistency enforcer, 96 defined, 95, 96 interpreters, 96 schedulers, 96 static rules-based models, 97–99 statistical probability models, 100 Inference modeling, 95–97 sensor data, 95–96 software leveraging, 96 Infrared location tracking, 220–21 fluorescent lights, 220–21 protocol issues, 221 Installation, 114–15, 120 Interpreters, 96 ISO/IEEE 11073, 81–82

J Journaling usage model, 210 K KMOTE, 22

Index

L Labeling, 112–13 Lab-on-a-chip, 36 Lab testing, 110–11 Link quality (LQ), 195 Location, 66 Location sensors, 213–15 Location tracking, 194–95 infrared issues, 220–21 methods, 194–95 Longevity, 5 Long-range communications, 25 Long-term user exposure, 66

M Machine learning. See Predictive analysis MagnetOS, 34 Maintenance, 115–16 Markov random field models, 101–2 MATLAB, 145 Matrix LCD, iMedTracker, 172 Medical regulatory, 66 Medication reminders activity beacon, 165, 166, 180–82 auditory-portable, 155, 159 bed sensor, 183–84 collaborative design, 160–62 collaborative design results, 162 door sensor, 185 ethnographic research, 153–54 ethnographic results, 162 field trials, 151–201 Health SPOT, 164–65, 174–80 iMedTracker, 164, 166–74 inference engine, 185–90 medication routines, 153–54 motion sensor, 184 participatory design, 160 PDRD, 166–85 phone sensors, 166 probe study, 154–60 probe study results, 162 problem statement, 151–52 reasoning system, 190–93 research objective, 152–53 sensor layout, 164 system description, 166–85 system software, 166 technical design, 163 technology selection, 163–66 text-wearable, 155–56, 159 use cases, 162–63

Index

visual-pervasive, 155 Medication routines, 153–54 Medium-range communications, 25 MEDUSA MK-2, 22 MICA, 22 MICA 2, 22 MICA2Dot, 22 MICA mote, 19–20 MICAz, 22 Microcontrollers, 20–24 defined, 16 sensor, 21–24 Microcontroller units (MCUs), 20 Atmel, 24 Texas Instruments, 24 Microprocessor and radio chip (MPR), 18 MITes, 22 Monopole antennas, 32, 33 Motes, 18–19 iMote, 20 MICA, 19–20 social health, 212 Motion sensors, 18, 166, 184, 212–13 Mulle, 22

N Network architecture, 14–16 Noncontact sensing, 225–34 Nymph, 22

O Operating systems, 33–34 common, 77–78 real-time (RTOS), 76 TinyOS, 18, 33–34, 76–81 Organization, this book, 1–2

P uPart, 22 Patch antennas, 33 Personas, 53 Pets, 222 Phone sensors, 166, 182–83 Physical transducers, 34–35 PicoNode, 22 Planning, 107–8, 117 Pluto, 22 Power, 16 HealthSPOT, 177 iMedTracker, 173–74 variation tolerance, 71

243

Predictive analysis defined, 95 limitations of, 97 Predictive models, 95 Preinstall, 113–14 Premarket testing, 113 Presence lamps, 215 Printed wiring board (PWB), 85 Privacy and security, 67 Probe study, 154–60 auditory-portable reminder, 155, 159 demographics, 157 device preferences, 158–60 participants, 156 procedure, 156–58 results, 158, 162 text-wearable reminder, 155–56, 159 visual-pervasive reminder, 155 ProSpeckz, 22 Prototype definition and requirements document (PDRD), 73–75 activity beacon, 180–82 bed sensor, 183–84 body-worn sensors, 141–43 clinical deployments, 136–45 defined, 73 door sensor, 185 example sections, 73–75 football sensor, 137–41 HealthSPOT, 174–80 iMedTracker, 166–74 miscellaneous sensors, 145 motion sensor, 184 phone sensor, 182–83 purpose, 137 software, 143–45 system description, 137–45, 166–85 video, 145

R Radio data rates, 69 enclosure, 85–89 HealthSPOT, 176 iMedTracker, 170–71 selection, 135 selection criteria, 133 standardized, 235–36 Real-time operating systems (RTOS), 76 Received signal strength indication (RSSI), 189–90, 193 decays, 197

244

Received signal strength indication (RSSI) (continued) in the home, 196–97 for location, 195 location awareness, 195–96 René, 22 René 2, 22 RFRAIN, 22 RISE, 23 Routing, 66

S Sampling circuit clock frequency supply to, 230 illustrated, 227 outputs, 230 from single clock pulse input, 229 waveforms generated by, 228 SB, 23 Scalability, 65–66 Scanning electron microcopy/energy dispersive spectroscopy (SEM/EDS), 86 ScatterWeb/E, 23 Schedulers, 76, 96 Security architectural model, 67 hardware, 70 Sensinode, 23 Sensors bed, 166, 183–84 biosensors, 35–36 body-worn, 141–43 chemical, 35 communications interface, 83 data, 95–96 door, 166, 185, 212 football, 137–41 for healthcare WSNs, 34–36 home trial illustration, 39 iMedTracker, 172–73 interfaces, 16 list of, 21–24 location, 10, 213–15 motion, 18, 166, 184, 212–13 phone, 166, 182–83 selecting, 10 technology, 135 types of, 37–39 SHIMMER, 18, 23, 143, 145, 147 Short-range communications, 25 Simulation circuits, 231

Index

Smart Antennas for Wireless Communication, 29 Smart-its, 23 Social health case study, 205–23 building materials, 221–22 caregiver journal, 216 clinical problem statement, 205–6 clinical requirements, 208 clinical research objective, 206 conclusion, 223 context ID application, 219 data to be collected, 210 deployment, 219–22 deployment schematic, 220 door sensors, 212 environment, 211 infrared location tracking issues, 220–21 location sensors, 213–15 mote, 212 motion sensors, 212–13 pets, 222 presence lamp, 215 radio enclosures, 219 requirements capture, 207–8 results, 222–23 social index, 208 software, 215–19 subject interaction, 210–11 subject journal, 216 system architecture, 207 system overview, 207 technology objectives, 206 technology selection, 212–19 technology selection criteria, 211–12 user modeling, 209–10 visualization application, 217–18 Social index, 208 Software conclusion, 85 considerations, 82–84 maintenance, 116 medication reminders, 185–90 PDRD, 143–44 questions, 82–83 selection, 136 selection criteria, 134 social health, 215–19 See also Technology Spec, 23 SpotON, 23 Squawk VM, 34 SquidBee, 23

Index

Star configuration, 15 Static rules-based models, 97–99 backward chaining, 98, 103 computational time, 99 example, 99 forward chaining, 98 if-clause, 97 implementation, 98 rules, 98 then-clause, 97 See also Inference engines Statistical probability models, 100 SunSPOT, 23 System-on-chip (SOC), 29 System validation, 145–46

T TCP/IP, 27–28 stack implementation, 27 WSN devices, 16 Teardown, 116–17 Technology field experience, 85–93 firmware choices, 76–82 football mapping, 135–36 hardware choices, 68–75 potential of, 5–9 selection, 63–93, 134–36, 163–66, 212–19 selection criteria, 133–34, 211–12 sensors, 135 social health, 206 software choices, 82–85 Telephone usage model, 209 TELOS/Tmote Sky/SkyMOTE, 23 Testing, 108–13 bench, 109–10 Bluetooth, 89–93 device-level, 108 documentation, 113 ethical review and labeling, 111–13 friendly environment, 111 lab, 110–11 participant, 122 premarket, 113 system-wide, 108 Text-wearable reminder, 155–56, 159 Time difference of arrival (TDOA), 31 TinyNode, 23 TinyOS, 18, 33–34, 76–81 components, 79 concurrency model, 80 defined, 76

245

execution model, 76 interfaces, 79–80 program architecture, 78–79 split-phase operations, 81 tasks, 80–81 threads, 78 T-Nodes, 23 Transceivers, 24–25 common examples, 18 defined, 16, 24 modules, 18 on wireless sensor platforms, 25 Tyndall Mote, 23, 24

U 3

U , 23 Ubiquitous displays, 236 Ultra high frequency (UHF) frequencies, 236 Ultrawide band (UWB), 28–29 Usage modeling, 1–2, 45, 52–54 benefits, 54 clinical deployments, 132 descriptions, 52 opportunity considerations, 53 process, 52–54 social health, 209–10 Usage models context ID, 209–10 journaling, 210 telephone, 209 visitor, 209 See also Social health case study Use cases, 54–55

V Video PDRD, 145 selection, 136 selection criteria, 134 Visitor usage model, 209 Visualization application, 217–18 Visual-pervasive reminder, 155

W WeBee, 24 WINS, 24 Wireless biomedical sensor networks (WBSNs), 7–8 Wireless regulatory, 66 Wireless sensor networks (WSNs) approach, 9–11 architectures, 14–16 at-home, benefits, 8–9

246

Wireless sensor networks (WSNs) (continued) for at-home care, 6–7 clinical deployments, 125–47 deployment, 107–23 functional requirements, 67–68 future, 225–36 generalized architecture for healthcare, 64–65 healthcare and, 1–11 principles, 9 radios for, 25–29 sensor/actuator module, 14 standardized radio, 235–36 system components, 16 TCP/IP and, 16 technologies, 16–36 transceiver module, 13–14

Index

use environments, 13 value to clinicians/caregivers, 8 WBSNs, 7–8 See also WSN devices WiseNet, 24 WSN devices, 68 architecture, 17 selection, 135 selection criteria, 133 system components, 16 See also Wireless sensor networks (WSNs)

X X10 motion detector, 18, 212 XYZ, 24

Z ZigBee, 27