Download Information

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Business intelligence wikipedia , lookup

Transcript
Information-centric networking in
Healthcare Scenarios
Going Beyond Physiological Sensing for Supporting Wellbeing
Work by the PAL project with partners being Cambridge University,
Essex University, Thales Research, HW Communications and MAC Ltd
User evaluation results by Dana Pavel as presented in MindCare 2011
workshop
Outline
• What scenarios do we consider?
• What information do we consider?
– And how to we visualize the information?
• What are the system-level implications &
requirements?
• Does it really matter? Do users want this?
2
Example: Lifestyle management
Bob is 55 and he has just
found out that he has a high
blood pressure and he is at
risk for developing a serious
heart condition in the future
unless he makes some
adjustments to his lifestyle.
3
Example: Lifestyle management
PAL System
4
Example: Lifestyle management
5
Some of the Challenges
Emergency Scenario
Produced by CTVC Inc.
6
What Information to Consider?
And how to visualize it?
7
Complex user context
Availability
context
(people or
resource)
Social context
(communication,
identity)
Mental
context
(interest,
focus, etc.)
Temporal
context
(absolute,
relative,
duration)
Emotional
context
Activity
context
Physical context
(position,
direction,
distance, speed,
proximity)
8
9
Visualizations in self-monitoring systems
10
Daily story
Calendar-based
interface
Visualizations for information
collected and derived stored in the
personal database
Information collected on
demand from remote
servers
11
10:20am. Location: at home. It’s quiet. Using MS Word, writing in a document called
MyPaper_v1.doc. Quite active, it seems,
based on how many words per minute you
MindCare2011
typed. Weather today is cloudy/sunny.
12
2:30pm. Location: university. It’s a bit noisy, in a meeting. You are giving a
MindCare2011
presentation. Getting quite agitated,
it seems. Weather now is cloudy/sunny.
13
System-Level View
Requirements, implications, and
approach
14
Overview of Requirements
15
Key Issues Here
• Vast and diverse amount of information
• Security and privacy of utmost importance
– Policy-driven, even for informal lifestyle management!
• Must work anywhere, anytime and on any device
– Often said but difficult to achieve!
• Creating an understanding at user level is important
– Amended by contextual evidence, if necessary!
16
Network Awareness
Service Awareness
Our Architecture Vision:
Information (From) Everywhere
Information
Application
Policy
Framework
Middleware
Communication
Infrastructure
Governance
Components
17
Translated into An Architecture
Visualization
Manager
Interaction Manager
Applications/Services
Information
modelling and
correlation
(Information Agent)
Data
gathering &
transformation
Policy
Agent
Reasoning
Engine
DB
I/O
Component
I/O
I/O
I/O
Component
Component
Component
Visualizations/Interactions
Resource
Discovery
Component
I/O
Component
DB
Map/unmap/divert
Pub/sub
Policy
Engine
Middleware
PURSUIT Pub/sub
PUB
PUB
Publisher
Subscriber
Subscriber
Rendezvous
Point
Topology
Manager
Communication Layer
18
Our Approach at Communication
Level
Pub/sub
abstraction
Node Architecture
RP
ITF
TM
FN
Apps
All-Ethernet
wired & wireless
Evolutionary Approach
Fragmentation
Service Model
ITF
ITF
Network Architecture
IP
pub
sub
pub
pub
API
TCP
: Rendezvous point
: Inter-domain topology formation
: Topology management
: Forwarding node
Rendezvous
Topology
Caching
Helper
…
RP
RP
Rendezvous
Network
Error Ctrl
Forwarding
TM
TM
TM
Forwarding
Network
TM
FN
Forwarding
Network
Forwarding
Network
Forwarding
Network
Explorative Approach
19
Interesting Points in an All
Information-centric Approach
• Role of middleware
– Pub/sub on routing level already
• Policies
– Integrating information from lower layers
• Discrimination of data at network layer
– Policy-based routing based on, e.g., importance
• Late binding
– Enable anywhere in different ways!
20
Gathering Data
Motivation
Application
Server
 harvest intelligence out there
Applications
Mobile Device
 commoditize acquisition, shift value to
intelligence
Middleware
Technical Highlights
AIRS
IP
 Event-based architecture
 Transfers only relevant data
Android OS
IP
Embedded
Sensors
BT
 Allows for local & remote sensing
 Allows for aggregation done in mobile
 Utilizes standard Android APIs
BT, BT LEE,
RFID,Zigbee
IP
Stationary
multisensor
module A
 Supports more than 50 ‘sensors’, from
BT-attached (AliveTech ECG) over
system to logical information (such as
mood and weather)
 Open source
 Available on Android Market (search
for “airs trossen”)
21
Do Users Really Want This?
22
User-based evaluations
• Online survey available at:
http://ieg.essex.ac.uk/myror/survey/intro.php
• Ongoing user experiments focusing on:
1. What information is perceived as more useful?
2. What correlations are perceived as more useful?
3. How do people want to interact with the system?
4. How do people want to personalize their story?
5. What events are perceived as meaningful by the user?
23
Online survey (preliminary)
• 30 people
• Questions focus on:
– Self-reflective behaviours
– Building user-friendly interfaces for such systems
• Customizing interfaces
• Sharing
• Interactions
24
Self-reflective behaviours
Q1: Do you often think back about what happened during the day?
(Often/Not very often/Never)
Q2: Do you think about what triggered a certain emotion or
behaviour? (Yes/No)
Q3: Do you usually propose any change based on self reflection?
(Yes/No/Examples)
25
Means for self-reflection
26
System-related questions
Q6: Would you find useful having a system as presented in the
scenario? (Yes/No/Examples of useful information)
Q7: If you were to be using such a system would you like to be
able to see a story generated based on your activity data?
(Yes/No/Explain)
27
System Demo
AIRS & Diary
28
Conclusions
• Lifestyle management is increasingly
becoming important
– It is an information-driven scenario!
• Users not only want this understanding – they
want to be in control of it!
• Networking-level aspects impact viability of
overall scenarios
– Late binding and different abstractions important!
29
Acknowledgements to the Larger
Team
• Cambridge: Jat Singh, Jean Beacon
• Essex: Dana Pavel, Kun Yang, Ken Guild
• Thales: Adrian Waller, Glyn Jones, Sarah
Pennington
• HW: Souroush Honary, Daniel Essafi, Behzad
• MAC: Peter Gould, Ying Li
• Ericsson: Steve Campbell, Mike Wamsley
30
Thank you
http://www.palproject.org.uk/