A CLOSED-LOOP SYSTEM FOR PERVASIVE HEALTH Jong Hyun Lim Defense - - PowerPoint PPT Presentation

a closed loop system for pervasive health
SMART_READER_LITE
LIVE PREVIEW

A CLOSED-LOOP SYSTEM FOR PERVASIVE HEALTH Jong Hyun Lim Defense - - PowerPoint PPT Presentation

1 Department of Computer Science A CLOSED-LOOP SYSTEM FOR PERVASIVE HEALTH Jong Hyun Lim Defense Talk 19 October 2012 @ 2pm Maryland 214 2 Department of Computer Science Chronic Diseases and Outcomes Increased life expectancy, increased


slide-1
SLIDE 1

A CLOSED-LOOP SYSTEM FOR PERVASIVE HEALTH

Jong Hyun Lim Defense Talk 19 October 2012 @ 2pm Maryland 214

1

Department of Computer Science

slide-2
SLIDE 2

Chronic Diseases and Outcomes

Increased life expectancy, increased chronic diseases

  • Developing countries: estimated $84 billion spent by 2015 [1]

Traditional model of episodic care in clinic and hospital settings is not optimal. Recently spotlighted method: low-cost longitudinal monitoring using consumer medical devices

2

Department of Computer Science

slide-3
SLIDE 3

Pervasive Health Devices

The devices (mobile/static) continuously monitor peoples everyday condition.

3

Department of Computer Science

Bayer Contour USB Jawbone UP Withings wireless weight scale

slide-4
SLIDE 4

Pervasive Health Applications

Web/Mobile apps to visualize/analyze collected data from underlying systems and devices

Fitbit Activity Monitor

Web Servers

4

Department of Computer Science

slide-5
SLIDE 5

The Characteristic of Chronic diseases

Chronic diseases are complex and multi-factorial in nature (e.g., Obesity). Pervasive health applications that can combine multiple sensing streams from devices are desirable.

Department of Computer Science

5

slide-6
SLIDE 6

Challenge: Combining multiple sensor data

Department of Computer Science

6

Activity monitor Weight Dietary intake & Location Device Owners Developers

..... .....

Application for Obesity Web Server1 Web Server2 Web Server3 Data streams

slide-7
SLIDE 7

Challenge: low device utilization

Department of Computer Science

7

Activity monitor Weight Dietary intake & Location Device Owners Developers

..... .....

Application for Obesity Web Server1 Web Server2 Web Server3 Data streams Caregivers

No Connections to Caregivers !! (Open) Low device utilization

slide-8
SLIDE 8

Our Proposed Closed-Loop Model

8

Department of Computer Science

Data Collection & Application Development Activity monitor Weight Dietary intake & location Caregivers Providers All streams Device Owners Developers Intervention & Event Detection Feedback/Alerts/ Triggers/Survey

..... .....

Applications

  • Lim et al., A Closed-loop Approach for improving the Wellness of Low-income Elders

at Home Using Game Consoles, IEEE Communications Magazine, Jan 2012.

slide-9
SLIDE 9

Stovepipe Architecture [2]

An architecture of existing pervasive health systems

Activity Monitor

SQLite Device Driver HTTP, Security, OAuth MySQL Device Driver HTTP, Security, Basic

Wireless Weight Scale

WiFi

BlueTooth

XML JSON

9

Department of Computer Science

slide-10
SLIDE 10

Impact on Application Development

Activity Monitor

SQLite Device Driver HTTP, Security, OAuth MySQL Device Driver HTTP, Security, Basic

Wireless Weight Scale

WiFi

BlueTooth

XML JSON 1 N App for Obesity

Closed-Interface

  • no/limited data accessibility for application

development

  • At best, applications become a mixture of

heterogeneous protocols, message formats, and APIs Low composability and maintenance challenge

10

Department of Computer Science

slide-11
SLIDE 11

Impact on Application Development (Cont’d)

Activity Monitor

MySQL Device Driver HTTP, Security, Basic

Wireless Weight Scale

WiFi

XML App for Obesity New Devices:

Vertical-Integration

  • All systems components are tightly-

coupled for custom purpose

  • To integrate heterogeneous devices,

developers need to modify all components in the system

  • Time and cost are non-negligible

System extensibility challenge

11

Department of Computer Science

slide-12
SLIDE 12

Question on Architecture

What system architecture can improve application composability and system extensibility?

12

Department of Computer Science

slide-13
SLIDE 13

Our Approach

Main Ideas

  • For extensibility
  • Providing a set of modules to interface and integrate heterogeneous

devices easily

  • For composability
  • Open, uniform data access interfaces
  • Providing services that the application developers need

13

Department of Computer Science

slide-14
SLIDE 14

HealthOS

*

HealthOS is a platform that consists of clients and servers to collect sensor data and support application development.

* Lim et al., HealthOS: A Platform For Pervasive Health Applications, mHealthsys, Nov 2012

App Storage Space

Pipeline 3 Pipeline 1 Adapter 2 Adapter N Adapter 1

Smartphone Game Console Physiological Monitor HealthOS Server

Pipeline 2

Push HealthOS Client

14

Department of Computer Science

PC or mobile platforms A process running in Internet (e.g., cloud)

slide-15
SLIDE 15

HealthOS: Resource Exposition

  • Resource: devices, users, sensing data
  • Principle: REpresentational State Transfer (REST) [3]
  • Interfaces are uniform, universally available (HTTP)
  • Resource Hierarchy

15

Department of Computer Science

/<userID>/<device>/<deviceID>/<modality>/<command> ¡

http://lim.cs.jhu.edu/lim/fitbit/547945/activity ¡

(HTTP request from applications)

slide-16
SLIDE 16

HealthOS: Further Simplifying Application Development

RESTful Java APIs

  • Serialization (converts XML resources to Java Object)
  • Higher level abstraction (hides the details about communication and

security in HealthOS)

16

Department of Computer Science

slide-17
SLIDE 17

HealthOS: Sample Code

Department of Computer Science

17

<User> <UserID>lim</UserID> <UserName> <LastName>Lim</LastName> <FirstName>Jonghyun</FirstName> </UserName> <DeviceName>Fitbit</DeviceName> <DeviceType>Activity Monitor</DeviceType> <DeviceID>547945</DeviceID> <DeviceName>Zeo Sleep Manager</DeviceName> …..

[Without ¡API ¡: ¡retrieving ¡user ¡lim ¡device ¡information ¡

  • 1. HTTP requests to

http://lim.cs.jhu.edu/lim

  • 2. Authentication/security
  • 3. Parse XML Messages from HealthOS
  • 4. Use device information
slide-18
SLIDE 18

HealthOS: Sample Code

Department of Computer Science

18

HealthOS ¡healthos ¡= ¡new ¡HealthOS(“http://lim.cs.jhu.edu", ¡"lim", ¡"password"); ¡ User ¡user ¡= ¡healthos.getUserById("lim"); ¡ ¡ for(Device ¡device ¡: ¡user.getDevices()) ¡{ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡System.out.println(device.getName()); ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡System.out.println(device.getModalities()); ¡ } ¡

[With ¡RESTful ¡API ¡Code ¡Sample] ¡ 6 lines of code

slide-19
SLIDE 19

HealthOS: Applications’ Needs

pervasive health applications and systems have diverse preferences/requirements for their purposes.

App HealthOS Server Push Hospital EMR System Pull 1. Message Formats (CCD

[2])

2. Services (Push data) 3. Protocols (FTP) 1. Message formats (CCR [1]) 2. Data Translation

19

Department of Computer Science

[1] CCR (Continuity Care of Record) and [2] CCD (Continuity Care of Document)

slide-20
SLIDE 20

HealthOS: Satisfying Applications’ Needs

20

Department of Computer Science

HealthOS Server BioHarness Accelerometer data Daily Activity Monitor

Database

I want step counts data in CCR XML

  • 2. Connect database

Get accelerometer data

  • 3. Change accelerometer to

step counts

  • 4. Format in XML CCR
  • 1. HTTP request
  • 5. Return data in XML CCR:

<Body> …. <Description> step count .. …. <Value> 20 </Value>

slide-21
SLIDE 21

HealthOS: Pipeline

Reusable, configurable building blocks (called components) to support applications’ needs

21

Department of Computer Science

App HealthOS Server Push Hospital EMR System Pipeline 1 storage space Pipeline 2 Pipeline 3 components pool (HealthOS server) assemble

slide-22
SLIDE 22

HealthOS: Components in Pipeline

Each components are built based on component-based software engineering (CBSE). Component: a software entity encapsulating its implementation and interacting with each other through well-defined interfaces:

  • Each component defines provided and required interfaces and functions.
  • Developers can easily reuse components.

22

Department of Computer Science

DBConnector CCR_translator . <<component>> <<component>> ProvDBData CCRData Required Interface Provided Interface To client requesting data ReqDBData

slide-23
SLIDE 23

HealthOS: Adapters

Adapters: modules to interface integrate heterogeneous devices into HealthOS

23

Department of Computer Science

Adapter 2 Adapter N Adapter 1

Exercise monitor Game exercise Physiological monitor HealthOS Client 1 PC HealthOS Server Tablet HealthOS Client 2 Encrypted data

slide-24
SLIDE 24

HealthOS: Adapter Development

{ "packet": { "sleep":[ ["time_in_deep", "uint", 2, 1], ["time_in_light", "uint", 2, 2], , …] }, "devicename":"zeo", "adaptername":"zeo_adapter”, "interface”:”Bluetooth” …. }

  • Device abstraction: JSON script describing the semantics of devices

24

Department of Computer Science

time_in_deep time_in_light

Zeo Sleep Managers’ sleep message: (2 bytes unsigned integer)

slide-25
SLIDE 25

HealthOS: Adapter Development (Cont’d)

Zeo ‘s Device Abstraction Macro Scripts

[A new adapter for Zeo Sleep Manager]

Input

25

Department of Computer Science

Output

Communication with HealthOS Communication with Zeo Message Parsing, Formatting and Securing data

slide-26
SLIDE 26

HealthOS: Installing a New Device

26

Department of Computer Science

{ "packet": { ”vitals": [ [”o2", "uint", 2, 1], [”heartrate", "uint", 2, 1], , …] }, "devicename":”miTag", "adaptername":”miTag_adapter”, "interface":”USBserial” }

Wireless Physiological Monitor miTag (o2, pulse, etc.) 1 Developers compose a new device abstraction

slide-27
SLIDE 27

HealthOS: Installing a New Device

27

Department of Computer Science

User “lim” with miTag ID 2 + miTag abstraction

2 3

miTag_adapter HealthOS client

HealthOS Web services

URL request from HealthOS application: https://lim.cs.jhu.edu/lim/miTag/2/vitals

5

lim_miTag_2_vitals [Database Table] HealthOS server [Pipeline] lim_miTag_2_vitals

4

slide-28
SLIDE 28

HealthOS: Management

HealthOS provides device owners and caregivers additional management benefits.

RESTful API LookingGlass Caregiver, Data Owner HealthOS

....

Caregivers, Data Owner O2, Pulse Weight Balance O2, Pulse Weight Balance 1 2 3 N

....

1 (security and authentication methods)

[Stovepipe systems] [HealthOS]

28

Department of Computer Science

slide-29
SLIDE 29

Intervention and Event Detection

Department of Computer Science

29

HealthOS activity level weight trend dietary intake, location Caregivers Providers all streams Device Owners Developers Intervention Event Detection feedback/alerts/ triggers/survey

..... .....

applications

slide-30
SLIDE 30

Our Pervasive Health Study Using Game Consoles

Server Elders' Residence Balance & Weight Exercise Game Elders Clinicians' Data

Internet

Exercise Interventions: visit or call (Installed for two weeks)

30

Department of Computer Science

Study goal: Improve lower body strength of 21 elders to prevent fall Game design: users’ ability and motivator Result: mean score of lower body function improvement: 24%

slide-31
SLIDE 31

Problems

Low device utilization

  • 48.7% (for 16 participants who played the game more than 3 times)

No automatic way to detect and notify of events

  • For example, when participants did not use devices yesterday, send

reminder.

31

Department of Computer Science

slide-32
SLIDE 32

DailyAlert*

  • A mobile persuasion toolkit consisting of smartphone clients and

a Web server.

  • Alert: A message generated by DailyAlert server to notify, remind, feedback,

and survey device users.

  • Alert Model:
  • AlertTrigger (when): when to generate an alert.
  • AlertFormat (how): a composite document built by using Open Data Kit

(ODK). [2]

AlertTrigger Schedule

  • driven

Event- driven Conditional Message Form Text Audio Image Periodic AlertFormat Immediate

...

* Zhan et al., DailyAlert: A Generic Mobile Persuasion Toolkit for Smartphones, PhoneSense 2011 32

Department of Computer Science

slide-33
SLIDE 33

DailyAlert Use Case

User: user-friendliness and Controllability Caregivers: alert composability

  • 3. Render the form in

DailyAlert mobile

<Survey name=”survey1”> <Question> <Header>Is the pain</Header> <Options> <Option>very bad</Option> <Option>bad</Option> <Option>not too bad</Option> </Options> </Question>

  • 2. Import XML (and Schema) in DailyAlert

server and set AlertTrigger (everyday)

33

Department of Computer Science

  • 1. Compose an alert using

ODK GUI and export the alert to XML

slide-34
SLIDE 34

Data Composability for Caregivers

What DailyAlert lacks?

  • Caregivers’ composability on collected data
  • e.g., “if weight > 200 lbs, generate alerts” (threshold-based)
  • Ability to describe disease models in the system for

sophisticated data analysis and detection

34

Department of Computer Science

slide-35
SLIDE 35

Trend Finder: Design

Detection Algorithm Rule Definition (based on a statistical model or rule) Trend Finder Estimated Parameters

Input: sensor measurements Output: alerts/ notifications Input: users' requirements

Trend Finder is a system to plug disease models and provide caregivers (data consumer) better composability.

  • Detection algorithm: known mathematical models to plug in the

system

  • Rule Definition: a component to define on how to use collected data.

35

Department of Computer Science

slide-36
SLIDE 36

Trend Finder: Early Disease Detection

Input: weight

measurement from HealthOS

1 Output: µ

(an estimated parameter)

3

A rule based on a model: 10% weight loss in the past month

e.g., µ(1) - µ(30) ≥ 0.1 µ(1), generate an alert 4

Department of Computer Science

Weight loss in Chronic Obstructive Pulmonary Disease (COPD) study

  • Abnormal weight loss is indicative of high risk of having COPD.

Linear regression component

Time window (start date, end date) 2

  • G G G

G G G G G G G G G G G G G G G G G G

10 20 −2 2 4

µ

(lbs) (date) 140 150 130 9/30

36

slide-37
SLIDE 37

Trend Finder: Personal Health/Exercise Coach

37

* Pictures from APDM, Inc

Trend Finder Data from HealthOS 1. Gait, posture analysis algorithm: sit-to-stand, 7 meter walk-away performance, cadence, stride velocity, stride length, and etc.

  • 2. Detection Rules: if stride velocity < 30cm/s
  • r turning speed > 3 second, generate an alarm

to me.

Too many turns and slopes, modify routes John (patient, lower body limitation) Accelerometers, GPS Matt (doctor) Designing a personalized exercise routine For John

Department of Computer Science

slide-38
SLIDE 38

Trend Finder: Fault Detection

Fault

  • User fault: Users’ unexpected behavior or environment

affecting the quality and state of measurements

  • Software and hardware faults: Anomalies in hardware or

software

38

Department of Computer Science

slide-39
SLIDE 39

Trend Finder: Fault Detection

Approach

  • Data-Driven: the data that the devices report is the primary source for

detecting the presence of fault. Model data characteristics, such as spikes, glitches, and stuck-at value readings.

  • Incremental: use extra devices and combine multiple modalities.

39

Department of Computer Science

Time(date) EKG

(stuck-at)

EKG Unusually high heart rate Activity monitor

slide-40
SLIDE 40

Summary

Department of Computer Science

40

HealthOS activity level weight trend dietary intake, location Caregivers /Providers all streams Device Owners Developers DailyAlert Trend Finder feedback/alerts/ triggers/survey

..... .....

Application

  • Combine multiple streams

using adapters/pipeline/API easily

  • Focus on visualization
slide-41
SLIDE 41

Summary (Cont’d)

Department of Computer Science

41

HealthOS activity level weight trend dietary intake, location Caregivers /Providers all streams Device Owners Developers DailyAlert Trend Finder feedback/alerts/ triggers/survey

..... .....

Application

  • Find correlation among data
  • In-depth user data analysis
  • Easily compose/deliver alerts
  • Detect events of interest
  • Diminished management work
slide-42
SLIDE 42

Summary (Cont’d)

Department of Computer Science

42

HealthOS activity level weight trend dietary intake, location Caregivers /Providers all streams Device Owners Developers DailyAlert Trend Finder feedback/alerts/ triggers/survey

..... .....

Application

  • Timely triggers/feedback
  • Increased device utility
  • Connectedness
  • Selectively secure and share data
  • Improved health conditions
slide-43
SLIDE 43

Acknowledgements

  • Andreas Terzis
  • Scott Smith
  • Sarah Szanton (JHU School of Nursing)
  • Gerald Masson
  • Michelle Carson (JHU School of Public Health)
  • Laura Fisher (JHU School of Nursing)
  • I-Jeng Wang (JHU Applied Physics Lab)
  • Cathy Thornton and Debbie DeFord
  • Our HiNRG members
  • Razvan, Mike, Jayant, John, Yin, Marcus, Doug, Andong, Da, Victor

(sorted by time each person joined, not by personal preference)

  • Nayoung Alice Kim

43

Department of Computer Science

slide-44
SLIDE 44

References

Department of Computer Science

44

  • [1]: WHO, Noncommunicable diseases country profiles 2011.
  • [2] Estrin et al., Open mHealth Architecture: An Engine for Health Care Innovation. Science,

2010

  • [3] Roy Fielding., Architectural Styles and the Design of Network-based Software

Architectures, doctoral dissertation, 2000

  • [4] Ko et. al., MEDiSN: Medical Emergency Detection in Sensor Networks, ACM Transactions on

Embedded Computing Systems (TECS), Special Issue on Wireless Health Systems, 2010

slide-45
SLIDE 45

References (cont’d)

Department of Computer Science

45

  • [5] ABI Research. Wearable sports and fitness devices will hit 90 million shipments in 2017,
  • 2012. (slide 3: 90 million wearable fitness devices in 2017)
  • [6] Szanton et al., Increasing Balance in disabled older adults using a Wii-based exer-game: a

pilot study of feasibility and acceptability, Gait and Posture (in submission)

  • [7] Bishop & Associates Inc., Wireless Technologies Drive Use of Mobile Devices in Healthcare,
  • 2012. (50 million wireless health devices in 2017 [1])
  • [8] WHO, Obesity: Preventing and Managing the Global Epidemic. Technical Report Series, No

894, 2009

  • [9] Guralnik et al., A short physical performance battery assessing lower extremity function:

association with self-reported disability and prediction of mortality and nursing home admission, J. Gerontology, 1994 (SPPB)

slide-46
SLIDE 46

References (cont’d)

  • [10] C.R. Lyles et al., Qualitative evaluation of a mobile phone and web-based collaborative

care intervention for patients with type 2 diabetes, Diabetes technology & therapeutics, 2011 (smartphone frustration)

  • [11] Open Data Kit, http://opendatakit.org/

Department of Computer Science

46