遠距照護是指使用資通訊技術，協助照顧有健康問題需求的人，包括從預防及健康促進到安寧照顧，從食衣住行到住院的遠距陪伴，每個環節都有人在做一些嚐試。雖然這個名詞出現不算久，但有些遠距的型式已經在生活中發生。例如充斥有線無線電視及廣播的賣藥及賣健康食品其實就是透過串流媒體及CALL IN電信網路的遠距藥物諮商，只是因為內容不妥被歸入負面的案例。但從這個例子可以知道市場其實在那兒，只是還沒找到可普遍化的好的健康照護服務模型。

遠距照護突然變成顯學，主要是社會的一些自主發展，使得照護資源的缺口變得明顯或可預期的。最主要的原因，當然是小孩子愈來愈少的未來社會，快速老年化的社會使得大家擔心需要照顧的人愈來愈多，但能提供照顧能力的人愈來愈少，筆者就常自嘲現在所做是未了未來老了自己用。此外，健保的給付以急性照護為主，對於出院後一段時間或慢性病等無法康復甚至只能控制維繫生命的許多情形，愈來愈依賴其他的資源來補充。而隨著社會的文明化，對健康的期望以及對照護資源斷裂的感覺，從老人及病人以一直擴充到雖然少但備受重視的小孩、年輕人的美容減肥、上班族的壓力問題等，電視台賣藥固不足取，但商人敏感的嗅覺其實透露了人們對健康問題的渴望。當然還有因為大量工作外移至大陸及東南亞，產生大量的台商及台幹的台灣特有現象，這些遠地的工作人口除了可能有無法一起赴任的父老妻小，他們繁重的工作及應酬也造成他們本身健康問題，需要照顧但身邊沒有可以提供照顧的人。

除了使用者端需求的興起外，另一方面就是資通訊技術的發達，像以前遠距會談所需的ISDN及昂貴的視訊設備，如今許多電腦設備已經直接整合在螢幕旁邊，在爺爺奶奶的家裡擺個小筆電，設個按鍵可以直接跟小孫子視訊MSN就可以一解老人家的思孫之情。其實從網際網路初起，物聯網及網路生活家電就曾經火熱過一陣子，但環境未成熟，來得太早反而扼殺一些創意，如今只有網路媒體播放器有一定的成績。在今天雖然有些資通訊環境比較成熟，但許多照護設施要上網仍然面臨一些問題，因為許多基本模組無法做成像樂高機器人一樣Plug&Play，除了PC之外都其他資通訊界面還不是非常的成熟，但對非重度電腦使用者而言，開台電腦只為了量個血壓實在不是一個合理的情境。

不管硬體環境進步到什麼程度，使用情境及服務內容仍然是所有的遠距照護應用的重心所在，而遠距照護平台則是為了串連起情境，在需要的時候讓被授權的人能取得內容資訊的硬體環境。它真的就應該像樂高機器人，可以針對特定的服務，用標準化的模組堆出所需的應用系統。情境的設計一般會以使用者端佈建的環境，區分為居家、社區與機構。社區與機構有一些獨立的成功案例，但因這兩者已有現成的人力配置，遠距照護是以支援現有人力為主。居家則一直停留在概念階段。雖然居家的數量級較大，有可能大量生產，但整個架構尚未成熟，每個服務都需要各自的設備及佈建而且互不相容，設備本身的穩定性也未到達一個程度，加上費用的考量，付得起一堆服務費的人往往選擇直接聘請照顧服務員從事這樣的工作。

至於服務的內容，無論從哪個維度展開，都是洋洋灑灑一大串。以照顧的對象而言，從老人、小孩、過勞的工作者到在照顧別人的人都需要受照顧。以健康狀況來分，則從健康人的保健、急性期、出院照護到慢性病及安寧都有需求。提供的服務從食衣住行育樂的生活照顧、到護理復健的醫療照護以及社群聯繫、遠距咨詢等可能列一列會將近20類。所承載的資訊也從最常被提及的生理資訊上傳、電子病歷界接到多媒體影音娛樂、心靈伴侶都有。

其實每個環節每種服務都有人在投入，這兒一一列舉佔掉太多篇輻。只是現在的狀況是每個實作都必須包山包海，比較模組化的也是侷限在PC的Windows架構中，對於需要嵌入式其他小型環境都必須高度客製化。而包山包海對多數的開發者而言都只能做好專業的一小部份，其他的可能就很普通；例如現在做生理訊號上傳設備者都必須自建伺服器當Call Center，但對硬體廠商而言建出來的伺服器實用性及有效性都不足。

現在一提到遠距照護平台，許多人就想到整合這些現成服務的雲端資料中心，其實是倒因為果的講法。過去網路基礎層的協定有許多種、網路服務也有許多種，但TCP/IP及WEB的成為標準，才是網際網路應用大爆發的原因。同樣的，雲端資料庫提供健康歷程檔案是重要的服務，但平台並不是收集資料、而是提供有益的資訊。現在只是因為服務都各自獨立，所以大家引頸企盼的是一個整合服務的架構，但這個東西往往是市場決定的，就如當初TCP/IP及WEB都不是為了要今天的網際網路而規劃的。如果在可見的將來，我們很容易在網路上建構一個健康照護的、跨越軟硬體的服務解決方案，一如今日很多服務都是在PC上實作的，那這些服務之間呈現的平台究竟是什麼樣子?整個大架構大致上來講如圖所示：

一般討論照護平台時都是問題導向的，從受照顧的人為核心開始，討論有什麼問題需要被關注。但因為有許多受照顧的人的狀況不佳，除非特定的情境，一般假設實際客戶端操作者為實際照顧者，但在許多情況下實際照顧者的電腦操作能力也儘限於點選跟輸入簡單的資料，即使他有更好的電腦操作能力也不一定有時間在電腦作業上。這也是為什麼客戶端必須脫離PC，以操作一般家電情境為準的原因。另外也會假設包括主要照顧者在內，並無健康照護的專業背景，而需要照護平台的協助，所以客戶端除了收集資料，必須有互動的能力提供一些回饋給使用者，否則對使用者而言是在做毫無意義的事情，必然不能持久。

再拉出來是服務端，目前的服務端都是以個管師為主要操作者，而個管師的來源主要是護理背景或是社工背景的人。很多人都認為遠距照護可以直達醫護人員，實際上醫護人員還是以醫院的病患為主要業務，其實也沒太多時間再負擔院外的病人。個管師這邊的系統雖然可以接觸到一些特別的需求，如電子病歷等，但是實際上比較接近所謂客服的系統，而且大部份的作業還是個管師的人工作業，只是資訊是以什麼形式再發佈到客戶端或其他提供支援的人。因為目前的系統都比較被動，個管師的個人特質對服務的成敗影響很大；雖然理論上個管師應該扮演顧問的角色，但實際上如果個人熱心不足，只是被動的根據系統事件作反應--例如受照顧者沒量生理訊號已經數天了，個管師只是口頭提醒而未探究沒有繼續使用系統的原因--則整個系統的效益會呈現不出來。另一方面，整個平台的好壞，除了協助客戶端的照顧服務提供者，也是從是否能提供個管師更多的協助來作評估。

再往外拉就是整個計劃的各合作伙伴，從醫護人員、營養師、藥師、復健、生活服務等不一而足，扮演各種資源提供者的角色，而遠距照護平台就是透過資通訊技術，將原本斷裂的某一些照護資源連結起來。至於這些合作伙伴如何使用平台，一如前文所述，目前各服務都是各自獨立發展，除了醫生可以在門診時透過平台查閱一些資料外其實並無共識。有些計畫有醫院作背景，合作伙伴都是同事，遠距照護平台與醫院系統一致性高，但有些計畫的這些合作伙伴來自不同環境，資源的管理責任又回到個管師或社政單位上。理想的遠距照護平台當然是這些合作伙伴不是為某一個特定的服務計畫提供資源，而是他可以透過平台提供資源給需要的人並收取其相對的報酬。

平台的功能是收集資料，提供處理後的資訊，資料及資訊的內涵，以及處理的知識，當然依服務設計而定。不過從整體而言，功能約略能分為以下四個大項並以常見的服務為例說明：

• 警示提醒：警示提醒類似一般檢查的紅字，只是遠距照護所提供的警示提醒針對的事件不只是生理數值，而且也不是對基本的標準做反應。例如已經被醫生告知高血壓的病人(通常知道時都已經滿嚴重的了)才會每天量血壓，這時候如果遠距照護平台只是反應血壓計上的是否高血壓其實並無提供任何功能，至少要能依病人狀況提供不同等級的反應，例如大於140/90給個黃燈、大於160/100給個紅燈，而這幾個數值應以醫生根據病人情形來決定，如果本來很嚴重突然掉到120/80以下也很危險。警示提醒又分為急性及非急性兩者，例如常見的跌倒偵測就是急性的，必須立即跟主要照顧者或就近的支援對象確認狀況，而一般生理量測就是非急性的，在個管師與照顧者的聯繫互動中一併處理。
• 趨勢分析：遠距照護平台所提供的健康歷程檔案是非常重要的管理資源，但只是將數據表列或畫成圖讓肉眼觀看，在客戶端沒有專業背景，服務端會是一對多的情形下，提供的幫助並不大。趨勢分析就像股票的技術線，透露一些會整的資訊，至少可以呈現出整體方向是變好、持穩、或是變差，還有生理訊號特有的控制是否穩定(血壓忽高忽低更容易中風)。
• 照護計畫：因為每個受照顧者及主要照顧者的情形多少不同，而且不像在醫院裡的照護計畫是針對急性處置、像是開刀就是傷口照護有簡單的表單，遠距照護都需要針對受照顧者的健康問題擬訂照護計畫。這種型式其實在傳統照護也有口頭或紙本的型式，但實施成果，像是慢性病的控制等其實都不理想，進到遠距照護平台如果只是呈現靜態的資料，效益恐怕也不會出現。目前情形都還有賴積極的個管師與客戶互動，看計畫實施上是否有需要幫忙提供衛教資料或連繫專業諮商人員等，未來的系統則應該增加對計畫內容的實施有自動化評值的能力，以提昇反應能力及減少個管師個人差異的影響。
• 健康評估：由於受照顧者的健康狀況是變動的，在照護的過程中健康的變化需要每隔一一段時間被評估以便告知客戶端現在狀況及注意事項。一般的評估可以分成經由檢驗檢查值如BMI等、自覺量表如憂鬱或壓力量表、以及由專業人員評估的如巴氏量表等。只是在遠距照護環境下不比在醫院裡，除了幾個傳統的慢性病或健康促進模型，要發展簡單而且有效的量測工具還有很大的努力空間，因為客戶端不具專業性，把醫院的東西移到家裡也不是個好主意。自覺量表則受到個案的偏差影響，敏感度不足，像是過勞的工作狂的壓力量表都很正常，他們並不自覺已經過度使用他們的身體。所以這個工作目前都是靠健康檢查、個管師評估及回診來進行，遠距照護平台則是提供資訊交換的管道，及未來會整資訊的可能性。

由於遠距照護牽涉的範圍很大，平台上是以服務為單位提供的，而服務基本上是問題導向的規畫。在規畫一個服務的時候，常見的迷思是從技術出發來思考我們有什麼樣的技術及設備，要如何應用在遠距照護。應該針對所提供的特定服務，請相關的參與者討論以下的問題：

1. 哪些被照護者的問題能被遠距的專業人員處理?
2. 哪些被照護者的資訊能被系統化?
3. 哪些操作可以由一般的主要照顧者協助進行?
4. 哪些評值過程可以被遠距化進行?

所以遠距照護的服務的開發，有幾個議題必須要注意，首先，一個遠距照護的服務開發牽涉到的人很多，因為資通訊技術不是傳統健康照護人員熟悉的，常常落得技術人員跟照護人員對立的情況。事實上，一些成功的案例往往是技術人員本身在自身或自己照顧親友時獲得的體認，反而能順利推行；但整體而言，讓技術背景跟照護背景的參與者能互相有對方的經驗，這種跨領域的整合--包括教育部推行多年的跨領域課程--其實難度比遠距照護還高得多。在沒有具照護經驗的技術人員參與的情況下，主其事者務必要讓實際照顧者主導開發，雖然得面臨技術人員的反彈，但系統最後有可用性才有可能繼續發展下去。

另外，由於平台的模組化界面仍不存在，服務的開發仍需要垂直的整合。但大部份計畫的經費不足，甚至許多只是研究生兼任計畫助理做的產品，受到技術水準、時程及開發工具的影響，最後還是在PC環境上建置雛型，但這些雛型的基本模組都是PC上現成的，也代表著不容易移植到其他環境。伺服器端可能尚可，因為個管師基本上是坐在辦公桌操作電腦、現在每個服務的人數也都不多，而且計畫大多有醫院背景，如果成型資訊室自然會接手，最多就是用Windows Server取代現有的硬體。

客戶端就比較麻煩，個人電腦再加一堆設備，安裝操作及保管、維持系統穩定都是問題，現在很多服務的中止都是因為客戶端常出問題維修不易。當然不是沒有人努力把PC驗複製到嵌入式系統去，如J2ME、OPENMOKO等，但還是沒辦法像PC一樣的成為氣候。大部份計畫客戶端都找外部廠商合作，但除了增加經費負擔外，廠商對照護經驗的更加陌生，造成客戶端的使用經驗更不順利。未來能否有一個取代PC，有開放界面作為模組化建構的基礎平台是重要的議題。有許多人期待Android，但Android尚未成熟，改版太快造成移植平台的困擾、硬體抽象層(HAL)並未公開使得自己擴充的週邊需要自己寫上層應用程式，還是不脫離傳統的做法等。

林林總總講了一大堆，最後的總結是這是一個發展中的環境，它不像電子產業已經成熟，設計晶片的、製造晶圓的、封裝測試的...每一個組織都有明確的層次跟定位。但這也是機會所在，雖然現在都得辛苦的搞定每個環節，但一旦某個服務被接受獲得大量的建置，很快的就會延伸出很多的應用，就如同早期的YAHOO一樣成為入口的掌握者而得到很大的成功。