Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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/