大學專題介紹 M-Kaigo老人心靈介護系統 Stanley (Yao-Yuan Chang) Advisor: Soe-Tsyr Yuan

Agenda 系統介紹 系統架構概述 情境介紹&系統展示 系統架構&決策流程 服務價值與特色 未來展望

Introduction 系統介紹

What is M-Kaigo? Kaigo Mind Kaigo My Kaigo 介護 心靈層面的照護 個人化 量身訂做 介護：日本介護保險制度於2000年實施，其制度立法依據為1997年的「照顧保險法」，該法規定日本介護保險制度於2000年施行。 介護保險制度屬國家立法的強制社會保險制度，但提供介護服務的，主要是由民間老人福利機構，政府（中央與地方政府）主要的功能與角色，是在籌措介護保險的相關財務。 Business model: 老人購買服務 企業販售服務 [可以e化, 不須用人工 (e-broker)] 帳戶金錢=>安排照護計畫=>submit給service provider (政府列10項) =>健保給付 專科護理師: 介護福祉士 台灣: 根據護理師狀況做安排, 忽略使用者偏好, 國內健保法令規定 一般而言醫院的成本較居家服務貴38% 介護比起一般中文所說的保護，更多了一層無微不至的照顧的概念，也就是心靈的溫暖，是種溫馨科技的概念，也是我們希望達到的一個境界。

Motivation 生育率降低 人口老化問題 老人需要關懷、希望能與家人住一起=>但是家人可能無法注意到生心理的異常=>推出老人照護資訊系統  藉由IS協助 不一定要送到安養中心 => 提高生活品質 

Example 中興保全 (經濟部技術處 銀髮族U-Care旗艦計畫) 遠距生理量測服務 衛教諮詢頻道 衛星定位協尋 居家照護派遣服務 遠距生理量測服務，乃使用儀器量測血壓、血糖、血脂、心跳，同時將資料傳送回管制中心儲存，建立個人健康帳戶，以供長期追蹤；一有發現異常，將會發出警訊給當事人及通知親友注意。 Minibond: 家屬即可隨時撥電話或上網查詢長輩的所在位置並回報 緊急狀況按SOS鍵就會送出緊急求救訊號 在遠端的照護上，還有急救的協助、慢性病配藥到府服務、及護士、志工定期探訪、醫療人力派遣、全省服務網連線等，都包含在居家照護的服務範圍內。

Existing Problems 老人照護偏重生理層面 需要家人的關懷 社交圈的限制 沒有為老人量身打造的整合性平台 鮮少關注老人心靈層面上的需求與服務

Existing Problems(cont.) 服務種類過多，難以選擇 無法在短時間內找到適合的服務 可用的服務受到使用者本身所有的可用資源限制 找到的服務不見得真正符合自身需求 在未來的生活中必定朝向科技化發展，人們會愈來愈習慣充滿e化服務的生活，過去的服務提供者所提供之服務，多半屬於被動式，必須等到使用者得知或認識某項服務後，才能進而去使用。……

Our Mission -建立服務整合平台 整合多樣化的服務，關注心靈層面需求 找到滿足年長使用者需求的服務 主動性、即時性與正確性 維持高齡者獨立、有尊嚴之生活品質

User Segment 年齡：50~70 歲健康的退休老人 語言：中文(通英語) 特性：會操作電腦 對於資訊科技不排斥 期望充實自己的退休生活

Care Elements Protection Want Worry Love supervision, medical attention, or protection. Want to feel affection or attraction Worry the object of concerned attention Love a person, activity, or object for which one has great affection or strong liking Protection:一個人之最基本需求 實體或醫藥方面的照護 (中興保全 實體照護) Want: 想被關注以及求知的欲望 Worry:對外在事物的煩惱 擔心在意的事物 Love:對人或對事物的一種喜好的情感 一個人的基本需求可以歸在此四種關懷元素中，我們專注在Love Want 以及worry

Framework Briefing 系統架構概述

Operating Flow 發掘 需求 分析 需求 尋找 服務 呼叫 服務 滿足 需求 Sensor收集資訊

Senario and Demo 情境介紹 & 系統展示

Scenario 故事主角：阿華 (60歲，剛退休的中年人) 目前從經理的工作崗位上退休 妻子仍在工作 子女在國外求學/定居 通英文 會使用電腦 對資訊科技並不會排斥 退休後希望能好好享受人生…

Scenario 1 想念居住在遠方的兒女 顧慮到一旦向子女說出口， 會令他們擔心 Q1：有什麼樣的解決方案， 可以替阿華排解相思之苦？ 08:00 AM, morning 想念居住在遠方的兒女 顧慮到一旦向子女說出口， 會令他們擔心 Q1：有什麼樣的解決方案， 可以替阿華排解相思之苦？

尋找適合的服務 專屬使用者的 虛擬決策團隊 進行垃圾桶模式決策 環境對應出 使用者的寂寞 這是後端的平台 用來收集sensor所收集的資訊 然後加以分析 做為提供服務決策用 (使用者是看不到的)

找到service 提供給使用者 使用者的決定會feedback給系統 做為下次決策的參考 因此可以持續改善服務的品質

提供的服務是WebCommunity 分為個人區以及公開區 個人區=>朋友家人 公開區=>社區鄰居等等… 有討論版 還有相簿 短訊 生日也會貼心提醒

相簿

老爸寂寞囉！ 該跟老爸聊聊了 平台也會寄mail給兒女 通知此一情形

與老張喝茶的約會!

Scenario 2 之前約好跟很久不見的老張去貓空喝茶 退休之後身邊沒有助理幫忙 搜尋資料和紀錄每天的活動都分外辛苦 11:00 AM, noon 之前約好跟很久不見的老張去貓空喝茶 退休之後身邊沒有助理幫忙 搜尋資料和紀錄每天的活動都分外辛苦 Q2：有沒有更方便的機制， 讓阿華能夠更輕鬆管理每天的行程呢？

這是我們的另一個示範性服務 Scheduler 除了事件管理之外上面也提供地圖與路徑規劃的功能 另外也可做為Sensor 將裡面的資訊提供給平台

Scenario 3 去喝茶過程中遇到許多朋友，與朋友一道回家 想跟大家找點樂子。 2:00 PM, afternoon 去喝茶過程中遇到許多朋友，與朋友一道回家 想跟大家找點樂子。 Q3：除了在外的活動之外，待在家裡有沒有更多 選擇能排解無聊及打發時間？

Service Remote Control 服務遙控器 除了平台主動提供服務之外 我們也提供了服務遙控器 供使用者被動呼叫用 服務遙控器是從UDDI中抓取服務的列表 並列出其服務描述 何謂UDDI呢( Universal Description, Discovery, and Integration) 在SOA的架構下 服務提供者可以將服務publish到UDDI 供requestor查找 呼叫

電視 KTV 遊戲 電影

Scenario 4 想要學習烹飪的技術 無師自通，效果畢竟有限 想要請教更專業的人有關烹飪的技巧 Q4：有沒有專屬於阿華的老師？ 6:00 PM, Evening 想要學習烹飪的技術 無師自通，效果畢竟有限 想要請教更專業的人有關烹飪的技巧 Q4：有沒有專屬於阿華的老師？ 老婆太辛苦 想要體貼他 做一道霸丸給他嘗嘗

金阿婆

Framework review and Decision Process 系統架構與決策流程

iCare Framework Needs identification 辨別使用者需求 透過sensor的環境資訊 與老人的歷史資料 推論現在的價值觀為何 Case based reasoning 分析老人行為模式與對應問題(既存的)間的關聯性，針對問題的狀況，近一步提供適當的服務與援助 Brainstorming: Intelligence agent技術，設計專屬的agent出席腦力激盪會議，agent之間溝通 知識分享 自動啟動決策 Service Provision: 尋找合適服務 並且透過上面的位址呼叫服務 Adaptive EDA: 從價值的角度分析事件帶給使用者的效益 還有訂閱事件時考量的因素 建構出價值分類的體系 來描述事件 與使用者所重視的價值 調適事件 篩選事件 並主動結合服務 提供給使用者 total solution

Framework …… Garbage Can Model Sensor Needs Identification SOA Service Provision 電子祕書 社群 顧問 其他 服務 …… Services user

Framework(cont.) Sensor：記錄使用者目前所處之情境 Needs Identification 日期時間 溫度 所在房間 在家成員 Needs Identification 得知使用者情境後，將情境轉換成使用者價值觀，進而進 行需求分析。 (家庭,娛樂,朋友,時間,金錢) 將感應器所得到的情境向量，與使用者歷史價值觀資料來進行比較運算，推算得出目前情境所對應的價值觀向量。

Framework(cont.) Garbage Can Model 使用者有多重需求 無政府狀態造成非理性且變動的決策 理論四要素 模糊的偏好 不明的決策技術 流動的參與者 理論四要素 問題<=>需求 參與者<=>決策角色 選擇機會<=>服務類別 解決方案<=>服務描述 描述無政府狀態之決策過程。在傳統的組織行為中認為，組織的決策是理性的，然組織的實際決策環境，會受到組織內、外部各種情境因素的影響而被打斷或改變，進而對組織的決策過程或選擇行為產生干擾，造成某種程度的模糊性，因此無法進行理性決策。 垃圾桶模式決策理論即將選擇機會(choice opportunity)視為一個垃圾桶，垃圾桶當中容納了許多已存在之問題與解決方案，而這些問題和解決方案有可能是產生之初就被參與者給丟棄的，故稱為垃圾桶模式。參與者藉由參與選擇機會來解決環境所產生之各種問題，而決策則是上述四要素幾近隨機碰撞而產生的結果；垃圾桶模式的運作，必須有能量(energy)，其為參與者所能提供的注意力大小。 決策的energy在我們的系統裡則定義為使用者之資源(resource)。

Framework(cont.) MNR(Manifold Needs & Resources) BDI 修改過的Garbage Can Model 以垃圾桶模式考量使用者資源決定出適合的服務類別後，再 以BDI代理人決定出適宜的服務描述。 BDI 將系統視為一有理性的代理人，並有如人心智上的看法 Belief、Desire以及 Intention

Framework(cont.) <decisionoutput xmlns="http://decisionOuput/ns/do/1.1"> <function>givingIndividual</function> <scope> <heterogeneity>true</heterogeneity> <profileMatched>true</profileMatched> <reachability>true</reachability> <local>true</local> </scope> <source> <socialNetwork>true</socialNetwork> <relationshipProximity>true</relationshipProximity> </source> <type> <dataOriented>true</dataOriented> <multimedia>true</multimedia> </type> </decisionoutput> 經過garbage can之後 產生的XML

Framework(cont.) SOA Service Provision 至UDDI註冊中心尋找服務 呼叫服務 元件 服務類別(service function category) 服務參數(service parameter) 元件 Dispatch Agent Service Discovery Service Invocation 指派元件(Dispatch Agent) 此元件負責接收外部事件與服務的要求，並將要求分派給負責處理的元件。 服務尋找元件(Service Discovery) 此元件負責尋找UDDI 註冊目錄中合適的服務，尋找的方式為利用服務的篩選條件尋找符合條件的服務描述。 服務呼叫元件(Service Invocation) 此元件可利用服務的WSDL描述呼叫服務。

Decision Model

Four Features 可擴充性 針對 使用者 特性設計 個人化 即時且主動偵測 使用者需求

Easy Expansion 針對 使用者 特性設計 可擴充性 即時且主動偵測 使用者需求 個人化 Web Service SOA 本系統強調SOA&web service架構的條件下，系統既定服務也可在日後加以擴充整合，提供更具彈性及應用性的服務系統。

User Friendly 使用者介面 反應速度 針對 使用者 特性設計 可擴充性 即時且主動偵測 使用者需求 個人化 提供互動性強、多媒體程度高的服務取代目前多數為純文字型態的服務，另一方面考慮老年人的學習能力，因此本系統從整合使用者偏好、資源效益到取得服務成為完整的循環步驟，致力減少過多複雜的操作。

Customization 針對 使用者 特性設計 可擴充性 即時且主動偵測 使用者需求 個人化 針對資源價值觀進行判斷 feedback 可藉由系統蒐集的使用者資料，針對不同使用者的使用習慣及背景提供最適切之服務，滿足其需求。

Proactive 針對 使用者 特性設計 可擴充性 即時且主動偵測 使用者需求 個人化 也可被動等候使用者呼叫 透過Sensor每隔一段期間蒐集使用者需求及環境資訊，並透過平台運算提出服務建議。 也可使用遙控器 被動呼叫

The Value and Features of Care Service Examplar 示範性服務價值與特色

Ubiquitous Social Life 電子秘書 e-Secretary 無所不在的社交生活 Ubiquitous Social Life 智囊團顧問 Dr. I

電子秘書 e-Secretary 目標： 個人化目標的前哨站 期望透過電子祕書可以自動主動式的偵測使用者 的需求，而不是使用者被動的索取服務。 功能 Scheduler Map Sensor

無所不在的社交生活 Ubiquitous Social Life 目標： 提供老人在家也可以隨時得到外界的最新資訊、交友等 經營無所不在的生活圈 功能： 讓老人能輕鬆經營自己的社群，分享自己豐富累積的生活 經驗 透過群組設定，克服距離的因素，隨時跟好友互通有無 相簿(Flickr API)、生日提醒、最新文章、站內訊息、 Skype ...

智囊團顧問 Dr.I 目標： 替有疑問需要解決的老人們提供諮詢服務的平台 特點： 專屬於使用者、一對一的顧問

Vision 未來展望

Assumption & Limitation 感應器數據是使用軟體模擬 開發過程中無硬體設備之支援 服務定價(iCare collaborate Design & Pricing) 研究範疇僅限於使用者需求的發掘、分析需求並提供服務 服務 示範性的代表服務 簡單服務/空服務，但系統可以處理並且呼叫 可擴充性

Future work & Vision 擴充服務 加入硬體sensor 整合生理健康照護 目前所提供的服務，除了示範性的代表服務之外， 其餘大多是較簡單的服務或是空服務，若是未來加入大量的服務 系統也能夠處理並呼叫，使本系統更加完整，具備更高的可用性 重點在平台!

Develop Tools 使用語言 程式開發 資料庫 Java, C#, JSP, PHP, JavaScript IBM Rational Software Development Platform Microsoft Visual Studio Macromedia Dreamweaver 資料庫 MySQL

Thanks For your listening Q&A