國立臺北護理健康大學資訊管理研究所碩士論文 National Taipei University of Nursing and Health Sciences
Graduate Institute of Information Management
指導教授：黃衍文 博士 潘美連 博士 Advisor: Ean-Wen Huang Ph.D.
Mei-Lien Pan Ph.D.
電子地圖及適地性服務導入長期照顧資訊系統之研究
A Study of Integrating Electronic Maps and Location-Based Services into Long-Term Care Information System
研究生：江佳蓉 撰 Name: Jia-Rong Jiang
中華民國一○六年七月
July, 2017
I
致謝
時光匆匆，轉眼間在北護也過了五個年頭，我永遠不會忘記當初因緣 際會之下，提出本校資管系的五年一貫入學申請，且順利成為預備研究生 的這段時光。在這期間真的遇到很多幫助我的人，我由衷地感謝，沒有你 們就沒有現在的我！
首先，我要特別感謝我的指導教授黃衍文博士及潘美連博士，在大學 專題時即受到黃老師的悉心指導，於研究所期間老師也時常給予我許多 能發揮的舞台，讓我在短短兩年的研究所生涯中累積了許多寶貴的經驗。
潘老師總是能夠指出我的盲點，並提供許多新想法幫助我思考，讓我能發 揮所長，有所成長。同時也感謝劉德明博士、邱瑞科博士與彭振興博士在 口試時給予非常多寶貴的建議與指導，使我的論文更臻完善。
其次，感謝邱淑芬博士，學長姊姿涵、皓怡、正峻、楷雯、立楷，同 學文欣、奕德、祖鵬、郁芳、驊洹，以及總是聽我抒發心情的萬年好室友 彥伶、時常教我各種知識的朋友詩翔，你們的幫忙與陪伴總是讓我感到特 別溫暖。
最後我要感謝我的家人，每當我熬夜疲累地回家時，總是為我準備許 多豐盛的飯菜甚至補湯來替我補充精力與體力；每當我受挫時總是給我 許多鼓勵、安慰與支持。感謝您們當我強大後盾，陪伴我完成研究所學業，
謝謝您們！
江佳蓉 謹誌於 民國106年7月 國立臺北護理健康大學 資訊管理研究所
II
電子地圖及適地性服務導入長期照顧資訊 系統之研究
研究所組別：資訊管理研究所
指導教授：黃衍文 博士、潘美連 博士 研究生：江佳蓉
時間：民國106 年7月
論文摘要
老年人口快速成長，促使長期照顧需求大幅增加，其中居家式長期照顧是一種到 個案家中服務的照顧方式，為因應其外出訪視需求，設計以行動裝置為導向的長期照 顧系統也逐漸成為發展趨勢。隨著資通訊科技的進步，電子地圖與適地性服務的應用 已越來越普遍，但在長期照顧系統的相關研究上並不多見，且現有研究主要較著重於 探討路線規劃等單一功能面，較少針對與系統整合方面等多功能的研究。
因此，本研究收集國內外文獻來探討地圖及適地性服務的應用如何與長期照顧系 統結合，並以 Web App 開發東部某醫院長期照顧資訊系統的經驗為基礎，建置一套 地圖及定位功能模組。系統使用HTML5地理定位來記錄訪視人員的所在位址，不但 能增加服務紀錄的正確性，也方便做人員調度與出勤考核的管理。利用Google Maps 路線規劃能計算訪問點之間的距離與總哩程數，可做為交通補貼參考。同時開發以地 圖方式取代傳統表單式陳列個案訪視資訊的功能，能更清楚查看個案分佈狀況與方便 地域相關統計資訊的呈現。由於系統以模組化方式設計，未來也方便擴充應用到居家 護理和日照中心的交通接送等相關長期照顧服務。
關鍵字：長期照顧、HTML5、電子地圖、適地性服務
III
Abstract
The growing aging population has increased the demand for long-term care. Long-term home care provides care services for people in their homes. In order to facilitate home visits, there is a trend toward mobile-device based tools for long-term care systems. With the rapid development of information technology, the use of electronic maps and location-based services have also become popular. However, much of the research in this area has not studied application of these technologies to home healthcare services. Moreover, current research typically focuses on a single function like optimal path planning instead of integrated multifunctional systems. Therefore, our literature review looked at domestic and overseas studies that may help to implement electronic maps and location-based services to a long-term care information system. We then established a map and location service module using a web app to develop a long-term care information system. HTML5 geolocation was utilized to record current staff location. This method improved the accuracy of service records and can also be applied to attendance management. Google Maps Directions service was utilized to calculate the distance between access points and total mileage, which can be a useful reference for route planning. Additionally, showing visit information on maps instead of a traditional appointment list can improve case distribution and present statistical graphics regarding a region. In the future, we will extend the system thru modular design to other long-term care services such as home care visits and transportation for day care.
Keywords: Long-Term Care, HTML5, Electronic Maps, Location-Based Services
IV
目 錄
致謝 --- I 論文摘要 --- II Abstract --- III 目 錄 --- IV 圖目錄 --- VII 表目錄 --- X 縮寫對照表 --- XI
第壹章 緒論 --- 1
第一節 研究背景 --- 1
第二節 研究動機 --- 3
第三節 研究目的 --- 5
第貳章 文獻探討 --- 7
第一節 長期照顧 --- 7
(一) 長期照顧目標與內容 --- 7
(二) 長期照顧的資訊需求 --- 8
第二節 行動通訊 --- 9
(一) HTML5 --- 9
(二) Web Services與 AJAX --- 11
(三) 行動裝置定位技術 --- 11
第三節 電子地圖及適地性服務 --- 13
(一) 電子地圖 --- 13
(二) 適地性服務 --- 14
(三) 電子地圖與適地性服務於醫療照顧領堿之應用 --- 15
第參章 研究方法 --- 17
第一節 研究步驟 --- 17
第二節 長期照顧系統建置方法 --- 19
V
(一) 資料新增元件 --- 22
(二) 資料修改元件 --- 22
(三) 資料顯示元件 --- 23
第三節 系統需求分析與設計 --- 25
(一) 需求分析 --- 25
(二) 架構設計 --- 28
(三) 系統測試及驗證方式 --- 51
第四節 相關技術及開發工具 --- 52
第肆章 研究結果 --- 53
第一節 經緯度轉換 --- 53
(一) 單一住址經緯度轉換 --- 53
(二) 批次住址經緯度轉換 --- 55
第二節 裝置定位 --- 56
第三節 地圖點位 --- 59
第四節 路徑規劃 --- 60
(一) 單一路徑規劃 --- 61
(二) 多點路徑規劃 --- 62
第五節 統計地圖 --- 63
第六節 系統測試及驗證 --- 66
第伍章 討論與結論 --- 69
第一節 討論 --- 69
(一) 研究過程 --- 69
(二) 訪視定位點呈現方式 --- 70
(三) 訪視定位點與個案住址之差異 --- 72
(四) 訪視定位點查核 --- 72
(五) 地圖平台選擇 --- 73
第二節 研究限制 --- 75
VI
第三節 未來展望 --- 76 參考文獻 --- 78 附錄一、期刊論文：應用地圖平台建置傳染病歷史資料查詢系統--- 88 附錄二、期刊論文：結合電子地圖及衛星定位的長期照顧管理系統之研 究-以偏遠地區餐飲配送服務之路徑規劃為例 --- 99 附錄三、期刊論文：整合新一代資通訊科技發展智慧型長照服務系統 --- 113
VII
圖目錄
圖1、現有長期照顧資訊系統之功能圖：目前有六大子系統，並透過資料
同步模組進行資料的上傳及下載 ... 4
圖2、研究流程圖 ... 18
圖3、長期照顧資訊系統使用流程圖：外出訪視時需先下載資料至行動裝 置中，待有網路環境時系統會自動將資料上傳至後端資料庫... 19
圖4、資料儲存在瀏覽器提供的 Web SQL 資料庫示意圖：將資料儲存於 Web SQL資料庫中能讓使用者進行離線操作 ... 21
圖5、資料新增元件使用範例 ... 22
圖6、資料修改元件使用範例 ... 22
圖7、單一欄位資料修改元件使用範例 ... 23
圖8、資料顯示元件使用範例 ... 23
圖9、離線資料儲存元件運流程圖：透過離線資料儲存元件可對 Web SQL 執行新增、修改、查詢語法 ... 24
圖10、離線資儲存元件架構圖：會將資料寫入於Web SQL 資料庫，待有 網路環境時會透過資料同步模組將資料更新至後端，虛線部份為本研究 之開發設計範圍 ... 25
圖 11、導入地圖及定位功能後的長期照顧資訊系統功能圖：本研究會建 立地圖及定位功能模組，並應用於送餐服務與居家服務中... 29
圖12、地圖及定位模組功能圖 ... 30
圖13、使用案例圖：使用者分為訪視人員與管理人員... 30
圖14、以表格檢視鄉鎮市區界線圖資 ... 34
圖15、不同色塊為篩選過後的獨立縣市 ... 35
圖16、系統架構圖，虛線部份為本研究之開發設計範圍... 36
圖17、經緯度轉換模組功能圖 ... 38
圖18、經緯度轉換模組架構圖，虛線部份為本研究之開發設計範圍 ... 38
圖19、經緯度轉換模組呼叫 Web Services回傳之JSON 格式 ... 39
VIII
圖20、經緯度轉換功能流程圖 ... 40
圖21、裝置定位模組架構圖，虛線部份為本研究之開發設計範圍 ... 41
圖22、裝置定位功能流程圖 ... 41
圖23、地圖點位模組功能圖 ... 42
圖24、地圖點位模組架構圖，虛線部份為本研究之開發設計範圍 ... 42
圖25、地圖點位模組呼叫 Web Services回傳之JSON格式 ... 43
圖26、地圖點位功能流程圖 ... 45
圖27、路徑規劃模組功能圖 ... 46
圖28、路徑規劃模組架構圖，虛線部份為本研究之開發設計範圍 ... 46
圖29、路徑規劃模組流程圖 ... 47
圖30、統計地圖模組功能圖 ... 49
圖31、統計地圖模組架構圖，虛線部份為本研究之開發設計範圍 ... 49
圖32、回傳之統計資料JSON 格式 ... 50
圖33、資料圖層產生功能流程圖 ... 51
圖34、個案服務評估表：收案時必須填寫此表單才能新增個案 ... 54
圖 35、經緯度模組導入長期照顧資訊系統中的程式碼片段：將經緯度轉 換模組回傳之座標利用資料儲存元件存入資料庫中 ... 55
圖36、經緯度轉換系統介面：經緯度轉換前後對照圖... 56
圖 37、裝置定位：首次登入服務紀錄頁面時，瀏覽器會要求使用者提供 位置資訊 ... 57
圖 38、居家服務員外出服務時填寫的排班行事曆，按下開始服務與結束 服務之後，便會將定位經緯度與表單資料一併儲存於資料庫中 ... 57
圖 39、送餐員外出送餐時填寫的當日送餐紀錄單，按下交付鍵之後，便 會將定位經緯度與表單資料一併儲存於資料庫中 ... 58
圖 40、在長期照顧資訊系統中新增定位資訊程式碼範例，僅需在表單中 增加一行程式碼即可，不會影響到原本表單的功能運作 ... 59
圖 41、地圖點位：將個案住址點位於地圖中，可點擊標記查看詳細資訊
IX
... 60
圖 42、地圖點位：將定位資訊及個案住址顯示於地圖中，可查看外出訪
視人員打卡的時間位置，也容易呈現打卡位置與個案住址的差距 ... 60 圖43、點擊查看地圖按鈕即可產生訪視路線圖 ... 61
圖 44、點擊標記內容之導航至此處按鈕即可連結至 Google Maps 中進行
路線導航 ... 62
圖 45、多點路徑規劃示意圖：利用訪視人員的定位紀錄進行多點路徑規
劃，可手動調整路線以計算出更精確的總距離 ... 63
圖 46、若在統計報表進行全區統計資料查詢，查詢列下方便會產生統計
地圖超連結 ... 64
圖 47、統計地圖：以顏色深淺表示區域人數多寡，滑鼠移過可查看此地
區人數數量 ... 65
圖 48、個案住經緯度距離計算頁面：可計算出個案住址與訪視人員進行
裝置定位之誤差 ... 66
圖49、訪視人員位置呈現：上方使用的為 Google Maps Roads API，下方
是本研究的路徑規劃模組加上地圖點位的成果 ... 71
圖50、Google Maps 能精簡地圖樣式，省去道路、文字、地形、色彩等資
訊 ... 75
X
表目錄
表1、離線資料儲存元件所需參數 ... 21
表2、離線資料儲存元件參數涵義對照表 ... 21
表3、合作醫院長期照顧系統中與地域相關之統計報表... 27
表4、使用者角色定義表 ... 28
表5、載入 Google Maps JavaScript API的基本程式碼範例[13] ... 43
表6、地圖點位模組所需參數及說明 ... 44
表7、相關技術及開發工具 ... 52
表8、個案 A與住址誤差距離計算表 ... 67
表9、個案 B與住址誤差距離計算表 ... 67
表10、個案C與住址誤差距離計算表 ... 67
XI
縮寫對照表
英文縮寫 原文 中文名稱
AGPS Assisted Global Positioning
System 輔助全球衛星定位系統
AJAX Asynchronous JavaScript
and XML
非同步的 JavaScript 與
XML技術
API Application Programming
Interface 應用程式介面
CSS Cascading Style Sheets 層疊樣式表
D3 Data-Driven Documents 資料驅動文件
DOM Document Object Model 文件物件模型
GIS Geographic information
system 地理資訊系統
GPS Global positioning system 全球定位系統
HTML5 HyperText Markup
Language 5 超文件標示語言第五版
HTTP HyperText Transfer Protocol 超文字傳輸協定
IADL Instrumental Activities of
Daily Life 工具性日常生活活動
ISP Internet Service Provider 網際網路服務供應商
JSON JavaScript Object Notation JavaScript 物件表示法
LBS Location-Based Services 適地性服務
LTC Long-Term Care 長期照顧
ODbL Open Database License 開放資料庫授權條款
XII
英文縮寫 原文 中文名稱
OECD
Organization for Economic Co-operation and
Development
經濟合作暨發展組織
OSM OpenStreetMap 開放街圖
RWD Responsive Web Design 響應式網頁設計
SOAP Simple Object Access
Protocol 簡單物件存取協定
SQL Structural Query Language 結構化查詢語言
TWNIC
Taiwan Network Information
Center，TWNIC 臺灣網路資訊中心
UDDI Universal Description,
Discovery, and Integration 統一描述、發現和集成
W3C World Wide Web
Consortium 全球資訊網協會
Web App Web Application 網頁應用程式
WSDL Web Services Description
Language 網頁服務描述語言
XML Extensible Markup Language 可擴展標記語言
1
第壹章 緒論
第一節 研究背景
人口高齡化是全球趨勢，近年來我國老年人口比例大幅增加，在民國
82 年已達 7.10%，邁入高齡化社會。根據國家發展委員會民國 105 年至
150年中華民國人口推估，預估民國107年我國老年人口比率將超過14%， 邁入高齡社會，民國 115 年老年人口比率將超過 20%，成為超高齡社會 [1]。人口高齡化所帶來的影響之一即是慢性病和功能障礙盛行率上升，
因此長期照顧的需求也隨之增加[2]。為緩解高齡化所帶來的社會問題，
行政院於民國105 年通過「長期照顧十年計畫2.0」，此計畫在民國105 年 11月陸續開始試辦，106 年正式上路，107年逐步拓展至全國實施。除原 有的長期照顧十年計畫的服務對象之外，另外擴大納入50歲以上失智症 者、55 歲以上失能平地原住民、49 歲以下失能身心障礙者以及 65 歲以 上衰弱老人等4類服務對象，預估服務人數將會由原本約51 萬1千人增 加至約73萬8千人[3]。
隨著科技蓬勃發展，行動裝置持有率普及，在2014年已達近7成[4]， 幾乎已成為人們不可或缺的物品，且行動醫療及健康相關的行動應用程 式也已經是成長最快速的類別之一[5]。根據臺灣網路資訊中心(Taiwan
2
Network Information Center，TWNIC)2016年臺灣寬頻網路使用調查報告
結果指出，全國12歲以上行動上網率達67.3%[6]。行動裝置結合網際網 路使隨時隨地查詢周遭資訊及取得所在位置已經非常普遍，進而讓適地 性服務(Location-Based Services，LBS)的應用受到重視[7]。現今行動裝置 及行動網路的普及，令適地性服務的發展逐漸成熟，電子地圖所提供的服 務也越來越豐富。除了最廣為人知的 Google Maps 之外，開放街圖
(OpenStreetMap，OSM)也因免費及開放授權的優勢，被視為 Google Maps
最強大的競爭者[8]。OSM的概念啟發自維基百科的協作編輯與放資料庫 授權 (Open Database License，ODbL)，是一個自由而且開源的全球地圖。
可應用於旅遊地圖、分析商店情報、人口普查、導航、學術、甚至是商業 使用。OSM 在 2016 年 8 月底註冊使用者突破 300 萬人數，除了一般使 用者數量增加之外，許多商業公司也紛紛轉為使用OSM，顯示利用開放 內容來節省營運成本是個趨勢[9-12]。
現今許多電子地圖皆有開放應用程式介面(Application Programming Interface, API)，如Google Maps、Open Street Map及內政部的TGOS MAP API等，開發人員只要使用其API，便能嵌入其地圖服務做開發及應用。
如Google Maps提供許多 API，包括Google Maps Javascript API：自訂地
圖、Google Static Maps API：以極少量的程式碼提供可內嵌的簡單地圖影
像、Google Maps Geolocation API：根據手機基地台和 Wi-Fi 節點等相關
3
資訊回傳裝置位置、Google Maps Geocoding API：地址與經緯度之間的轉 換、Distance Matrix API：針對多個目的地和交通方式計算距離及所需時 間、Google Maps Directions API：多個目的地間的路徑規劃[13]等，開發 人員皆可自由搭配這些API來開發所需之功能。
第二節 研究動機
近年來電子地圖與適地性服務已被普遍應用，在醫療照顧領堿中，大 多數與電子地圖及適地性服務有關的研究主要都是呈現疾病分佈、路線 導航、或是著重於探討路徑規劃演算法，再搭配地圖呈現。在資訊時代，
長期照顧資訊系統應考量長期照顧服務的多樣化來設計，才能提升長期 照顧的管理與提供決策所需的資訊[14]。然而，上述研究大多都是將地圖 做為呈現結果的輔助工具或是只有單一功能的應用，很少有特別針對電 子地圖及適地性服務之應用如何與長期照顧資訊系統結合的相關研究及 探討。
目前使用資訊系統增進照顧服務品質以及經營績效已經越來越普遍，
本研究與東部某醫院(以下簡稱合作醫院)合作開發的長期照顧資訊系統，
目的即是為了能縮短文書作業時間，以及整合健康和生活照顧等相關資 源，進而提升長期照顧服務品質，希望能更有效落實偏鄉長期照顧服務。
與合作醫院建置的長期照顧系統中，目前已完成五個子系統，分別為居家
4
服務、送餐服務、家庭托顧、日間照顧及居家護理，現有系統功能架構如 圖1。其中居家服務、送餐服務、居家護理及日間照顧之交通接送為需要 由照顧人員至個案家中進行的服務。
圖1、現有長期照顧資訊系統之功能圖：目前有六大子系統，並透過資料同步模組
進行資料的上傳及下載
合作醫院已開發之長期照顧資訊系統功能如圖 1 所示，本研究在此 系統開發經驗討論過程中發現需要到宅提供的長期照顧服務，如居家服 務、送餐服務、居家照護等，在外出服務的同時若也記錄其位址資訊，將 有助於出勤考核之管理。目前系統皆以列表方式呈現訪視資訊，此方式較 無法清楚瞭解個案地理位置分布情況，若以地圖輔助呈現個案分布則能 提升訪視品質[15]，也有研究報告提到照管人員進行到府評估時，常常有 尋找個案地址之困難[16] 由此可知長期照顧服務提供過程中具有位址資 訊及地圖呈現的需求。
5
目前已建置的長期照顧資訊系統是以 Web App 及響應式網頁設計 (Responsive Web Design，RWD)，雖然方便讓訪視人員在行動裝置上進行 表單的填寫，但對於不同需求的服務卻沒有提供相對應的電子地圖及適 地性服務功能。本研究曾參與電子地圖相關系統開發，例如發表「應用地 圖平台建置傳染病歷史資料查詢系統」論文如附錄一，除了進行系統實作
也探討Google Maps與 Highmaps在地圖呈現上的差異與優缺點。因此本
研究建議合作醫院採用電子地圖及導入適地性服務，並以上線之居家服 務與送餐服務子系統為例，實際建置一個符合不同長期照顧服務項目需 求，且能通用於各長期照顧子系統的電子地圖及適地性服務功能。
第三節 研究目的
根據背景與動機所述，本研究首先探討電子地圖及適地性服務有哪 些主要功能可以廣泛應用於長期照顧系統中，並由過去以Web App 建置 長期照顧系統之經驗，將現有系統對電子地圖及適地性服務之需求做為 系統開發基礎，最後以居家服務和送餐服務為例，實際導入地圖及定位功 能，以模組化方式建置能提升系統的可攜性及可維護性，方便複製及擴散
於各種以Web App 建置的長期照顧子系統中。本研究之具體研究目的如
以下所述：
1. 收集分析國內外地圖及適地性服務於醫療照顧方面的應用，探討
6
其中可用於長期照顧系統中的功能，並整合至系統中。
2. 設計電子地圖及定位功能模組，提供管理者查看訪視人員位置，
做為人員調度與分派參考資訊。
3. 設計統計地圖功能，視覺化呈現統計報表。
4. 以居家服務及送餐服務子系統為例，導入地圖及定位功能，實際 呈現電子地圖與適地性服務於各長期照顧子系統中的應用。
7
第貳章 文獻探討
本研究利用電子地圖及適地性服務，實際建構一套地圖及定位功能 模組，並導入於長期照顧資訊系統中應用，因此本章以長期照顧、行動通 訊、電子地圖與適地性服務進行文獻的探討。
第一節 長期照顧
(一) 長期照顧目標與內容
根據衛生福利部長期照顧十年計畫2.0核定本，長期照顧2.0 服務項 目包括長期照顧十年計畫1.0內原有的八大服務項目，並擴充其服務內涵 與增加服務彈性，如在交通接送的部份會考量偏遠地區的交通成本來進 行補助。除此之外，長期照顧十年計畫2.0也會提供失能照顧等服務，並 建立以社區為基礎發展連續多目標服務體系，落實在地老化，提供可近性 的照顧服務與提升照顧連續性[17]。
吳淑瓊等人指出世界主要國家的老人照顧政策皆以在地老化為原則 [18]。丸尾真美指出高齡者較喜歡於待在熟悉的環境中，因此建議讓高齡 者能盡量在其居住環境中生活[19]。由經濟合作暨發展組織(Organization for Economic Co-operation and Development, OECD)整理的各國長期照顧 發展經驗，可得知照顧體系應以在地老化為原則，並以居家、社區式的照
8
顧服務發展為優先[17、20]。
居家服務能讓高齡及身心障礙失能者不必離開熟悉的環境，由居家 服務員到宅提供一連串的照顧服務，也能落實在地老化的精神。也鑒於居 家服務員的工作場所主要在個案家中，因此吳淑瓊等人認為增加交通成 本的補貼是提升居家服務就業意願的重要因素之一[21]。
而在餐飲配送服務需求逐漸增加的情況下，彭琳的研究曾經針對到 府送餐服務的配送路線，設計一個高齡者餐飲配送之營運模式，藉由提出 之鄰域搜尋改善模組，能有效降低車輛的數量與行駛的距離[22]。
(二) 長期照顧的資訊需求
科技的進步使得資訊通訊技術應用於醫療照護領域的實例也越來越 多，這也促成了遠距照護與醫院護理系統的快速發展。然而，相較之下長 期照顧系統的發展較無上述系統快速，但全球對於長期照顧的需求卻是 持續增加，必須提升長期照顧系統的可用性，才能滿足人力資源有限的長 期照顧大量需求[23]，因此運用資訊科技工具來輔助長期照顧服務是必然 的趨勢[24]。
在長期照顧資訊系統的相關研究上，莊坤洋就指出長期照顧資訊系 統應考量長期照顧服務的多樣化來設計[14]；朱宗藍等人指出完善的長期 照顧體系需結合科技、資訊及網路的發展，滿足行政、管理、與照護決策
9
的需求[25]。張皓怡曾經為了解決長期照顧服務大量紙本表單建置不易的 問題，應用模組化開發基本元件來建置系統，減少程式碼複雜度，提高系 統可維護性[26]。在長期照顧職能治療的部份，張瑞昆等人認為職能治療 應結合所有長期照顧專業來建構一個整合的服務系統，而將資訊科技運 用於個案的輔具、居家環境、日常生活活動等方面的服務，將會是長期照 顧職能治療資訊化的一大發展[27]；在應用方面，康家豪等人提出一個危 險事件偵測系統，主要偵測長期照顧上經常出現的危險狀況，當預測到或 已發生危險狀況時，便會通知照顧人員，來達到預防危險及減輕照護人員 負擔的目標[28]；羅家倫等人以全人照護理念開發了一個機構式老人照護 資訊管理系統，透過資訊系統來了解長者的健康照顧狀態，發生異常時能 及時處理，並提供報表及分析工具，協助解決高齡者之照顧問題，減少照 顧作業流程時間[29]。
這些研究皆是希望能透過資訊科技與長期照顧的結合，來輔助減少 人員作業時間、提升照顧品質以及提供資訊給照顧人員參考等。
第二節 行動通訊
(一) HTML5
HTML5 是目前 HTML 的最新修訂版本，現在已成為行動裝置普遍
支援的標準，它可以直接在網頁上進行影音服務應用、定位服務、介面控
10
制設計與離線資料儲存等應用。HTML5 包含 HTML、CSS 和 JavaScript 三個部分。除了原先的文件物件模型 (Document Object Model, DOM)介
面，HTML5 增加了更豐富且更多樣化的應用程式介面 (Application
Program Interface, API) ，以幫助創建Web App網頁應用程式。其中離線
網頁應用程式(Offline Web Applications)及 Web SQL Database，能將網頁 儲存於本機快取記憶體中，並透過 SQL 語法直接存取的本地端資料庫，
讓使用者能在離線的狀態下使用。而jQuery 是一個快速簡潔的JavaScript 函式庫，能簡化原本複雜的 JavaScript 程式碼，利用 jQuery 選擇器能快 速抓取欲選取的HTML 元素。
利用HTML5可建置跨平台的應用程式，且無需安裝任何外掛程式便
能使用[30]。在HTML5成熟的發展之下，越來越多人選擇使用 HTML 5 進行跨平台應用程式開發。洪正峻等人利用HTML5與Web SQL 建置應 用於行動裝置的疾病通報系統[31]；B. Ondov et al.利用 HTML5 和
JavaScript 建立生物資訊的視覺化圖表，可攜性高且容易呈現分析結果
[32]；O. Prilepova et al.使 用 HTML5 開 發 一 個 基 於 地 理 資 訊 系 統 (Geographic Information System, GIS)的 Web 介面，能夠基於地理資訊來 進行農作物生長模擬，並協助選擇合適的生長位置，可做為種植地點的評 估[33]。
11
(二) Web Services與AJAX
Web Services是一種可以跨平台的網路服務，由四個核心元件所組成，
分別為可延伸標記式語言(Extensible Markup Language, XML)、簡單物 件存取協定(Simple Object Access Protocol, SOAP) 網頁服務描述語言 (Web Services Description Language, WSDL)及統一描述和發現和集成 (Universal Description, Discovery, and Integration, UDDI) ，其以 Web的開 放標準為基礎(如 HTTP、XML 及 SOAP 等)，能為異質系統提供服務或 資料交換[34]。前端使用者可利用AJAX向Web Services提出服務請求，
而AJAX全名為Asynchronous JavaScript and XML(非同步的JavaScript與 XML 技術)，傳統的 Web 應用為使用者提交資料時，伺服器就會回傳一 個新網頁，但由於前後兩個網頁的 HTML 代碼大多相同，因此造成許多 頻寬的浪費。AJAX允許透過與伺服器交換資料來異步更新網頁，意即可 以僅取回所需的資料，無需重新加載整個頁面，能節省許多頻寬[35]。
(三) 行動裝置定位技術
GPS全球定位系統的全名為 Global positioning system，是基於衛星訊 號的定位系統，GPS的定位精確度極高，但由於GPS訊號易受天氣狀況 或大樓遮蔽物等干擾，導致訊號微弱而無法定位，因此在室內通常無法使 用。一般來說，有支援 GPS 的行動裝置會利用輔助全球衛星定位系統
12
(Assisted Global Positioning System, AGPS)來輔助定位。如上所述，由於 GPS 訊號易受環境影響，因此為了確保可正確接收到訊號，GPS 通常要 在室外且可以看到天空的寬闊環境下定位較精準，定位所需的時間也較 長。而 AGPS可以透過手機或 Wi-Fi 基地台訊號配合 GPS 訊號來進行定 位，可以加快定位速度也能提高定位精準度，因此被廣泛應用在手機與平 版電腦等行動裝置中[36]。
行動裝置定位除了可以應用在各種適地性服務之外，S. Saeb et al.也 透過收集由行動裝置定位而來的地理位置，利用位置特徵像是晝夜、平日 或週末的位置差異，來檢測位置與抑鬱症的關係[37]；E. Shim et al.也透 過收集行動裝置的定位與聲音傳感器所接收的資訊，來測繪一個噪音地 圖，有利於噪音監控[38]；Y. Xu et al.的研究中利用大型行動裝置定位軌 跡資料集，估計出一個城市在同一天中不同時間對自行車旅行的潛在需 求，並依此做為建置公共自行車站的位置分配與計算自行車的投放數量 的參考依據[39]；D. Donaire-Gonzalez et al.利用GPS設備及行動裝置定位 來追蹤使用者位置以進行環境健康風險的評估，並使用兩項設備的定位 資訊來計算定位誤差距離，其研究結果顯示行動裝置平均定位精確度為 25公尺[40]。
13
第三節 電子地圖及適地性服務
(一) 電子地圖
隨著科技進步，電子地圖提供許多地圖服務，應用也日益廣泛。P.
Dominkovics et al.的研究表示最好的呈現流行病學資訊的方式即是透過 地圖工具，而地理位置以通常在健康資訊中有關鍵的作用，因此其研究建 置了一個基於 Web 的結核病發病率的空間密度圖，使用互動式的地圖與 健康資料混搭能幫助衛生專業人員進行分析和任務決策[41]；L. Brasil, M.
Gomes et al.結合地理資訊系統和 Web 平台設計一個登革熱的分析及支援
工具，除了能對疾病進行統計與監控之外，也有助於分析疾病潛在風險 [42]；J. Nelson, S. Quinn et al.的研究介紹了一個基於網路的地理分析工具，
能尋找Twitter 上關於政治的推文進行案例研究，利用 D3.js與 GeoJSON
來呈現視覺化地圖，讓使用者可以比較地區人口特徵和政治資訊 ，
D3(Data-Driven Documents)為一套JavaScript 函式庫，能有效動態呈現視
覺化資料[43]。
與地圖相關的研究中，Google Maps 在各領域都有廣泛的應用。R.
Newton et al.利用 R語言產生地理空間統計分析資訊，並結合 Google Maps
以疊加層呈現統計資訊，能產生土壤污染地圖、人口密度地圖等統計地圖 [44]；I. Nyoman Piarsa et al.利用Google Maps 建立空間決策支援系統，透
14
過組合的空間資訊，如經緯度、區域和一般資訊如地點類別、地址、評價、
公司名稱等，將這些資訊標記於地圖中可幫助遊客尋找感興趣的市場[45]； 在土木工程方面，蕭釧瑛等人應用 Google Maps 整合環境品質資料倉儲 進行環境分析[46]。在教學上，張春蘭等人設計建立國中地理課程的範例
[47]；黃金聰將 Google Maps 應用於不動產交易的資料庫中[48]。也有學
者提出改善GPS定位精準度的方法，利用Google Maps 來將GPS接收的 座標資料繪制出點位地圖，並顯示演算結果與實際數據的對比[49]。
(二) 適地性服務
適地性服務(Location-Based Services, LBS)即是利用行動通訊網路或 GPS 取得行動裝置的地理座標，並依其位置提供各種相關應用的加值服 務。在適地性服務中，GPS已成為優秀的戶外定位系統[50]，其定位服務 廣泛應用於旅遊資訊、尋找興趣地點及車輛追蹤[51、52]等。在車輛之追 蹤、行進路線之規劃的部分，許佳興等人建置的自動車牌辨識系統結合
Google Maps將行車路徑即時顯示於地圖中，達到不需當街攔查也能查緝
贓車取締犯罪目的[53]；王月雲等人則利用Google Maps 開發一個自行車 定位系統，即時追蹤與回報騎乘者的定位資訊來提昇騎乘者的人身安全 性[54]。林垂頤則利用行動裝置定位與Google Maps結合台北市政府公開 資料平台建置行動地圖，提供使用者獲取與其地理位置接近的生活資訊
15
[55]；施啟煌等人建置了一個排隊叫號系統，可偵測使用者位置達到提醒 功能，避免過號及減少等候時間[56]；陳昀暄等人建置一個自行車租借系 統，能查詢個人位置與停車場資訊來減少尋找車位的時間，也能提供即時 的道路救援通訊服務[57]；張阜民等人建置了適地性的行動學習平台，能 記錄使用者在戶外的位置與活動軌跡，搭配與資料庫的結合，也能讓使用 者即時認識地區的老樹等資訊，提升學習效率[58]；饒瑞佶等人建置自行 車旅遊服務平台，能整合自行車業者與週邊的商業活動，依照使用者位置 提供適時的導覽服務[59]；V. Agarwal et al.分析使用者搜索醫療詞彙的紀 錄與地理位置，進行醫療保健的廣告推播，能有效增加廣告點擊率[60]。
(三) 電子地圖與適地性服務於醫療照顧領堿之應用
由於 GPS 的蓬勃發展，結合地圖及路線規劃導航等適地性服務應用 也日漸普及。在醫療照顧領域研究方面，R. Fleischman et al.使用了GPS
與Google Maps 來預測到達急診室的救護時間[61]；魏志誠等人研究建立
急難救助行動平台，結合Google Maps 與定位功能，提供使用者即時的適 地性服務，增加緊急應變處理能力[62]；鄧詠竹等人利用政府開放資料與
JavaScript開發了互動式的疾病死因地圖平台，能查詢在各地區的時空變
化與各種死因的死因統計，有助於衛生政策制訂及探討[63]。
在網頁應用方面，流感溫度計[64]可將流感疫苗院所及抗病毒藥劑院
16
所點位於地圖中，使用者可以查看其周遭的醫療院所資訊，另外也提供以 面量圖呈現急診、住院、門診的疫情地圖，以不同顏色標示各縣市的病例 增加百分比，能呈現各縣市疫情的嚴重程度；台灣傳染病標準化發生率地 圖[65]能動態呈現傳染病發生率地圖，另外還提供各鄉鎮區、性別、時間 趨勢等統計圖表，可查看歷年月傳染病的發生率；急診資訊整合平台[66]
以地圖呈現使用者附近醫院的滿床狀況，並能依距離遠近、看診人數、等 待病床人數等資訊進行最適醫院推薦與導航，使用者可依此平台選擇最 適合的急診院所。
在市面上，日本富士通推出在宅醫療支援 SaaS，只要點擊標示於地 圖上的病人住家，系統便會自動產生導航路線，出診醫師就可以在手機上 確認這些導航資訊。另外此系統也可透過 GPS 查看出診醫師目前的所在 位置，若有病患發生緊急狀況時，院內工作人員可根據出診醫師之所在地 與出診時程表來做出精確的出診指示[67、68]。
17
第參章 研究方法
本章節依序說明研究步驟、系統需求分析與設計、長期照顧系統建置 經驗與相關技術及開發工具。
第一節 研究步驟
基於研究背景、動機及目的，本研究於文獻中先探討長期照顧的資訊 需求，再深入了解近年來電子地圖及適地性服務在醫療領域的現況與應 用。系統建置初期會先以合作醫院需求為基礎，再經由參考上述之文獻探 討及相關應用，建置電子地圖及適地性服務可運用於長期照顧系統的功 能，最後以合作醫院上線進行測試中的居家服務與送餐服務子系統為例，
進行系統開發與測試，達成研究目的及具體應用。圖 2 為本研究之研究 流程圖。
18
圖2、研究流程圖
19
第二節 長期照顧系統建置方法
本研究將電子地圖及適地性服務導入長期照顧資訊系統中，為了達 到與長期照顧資訊系統架構的一致性，因此在進行系統開發前會先參考 與合作醫院建置之長期照顧資訊系統的開發相關經驗。
配合外出訪視可能遇到無網路的環境，長期照顧資訊系統在設計上 以離線為主。圖 3 為長期照顧資訊系統之使用流程圖，訪視人員在訪視 前會先將訪視資料及電子表單下載至行動裝置中，外出進行訪視時填寫 之紀錄會暫存於Web SQL 資料庫，待回到院內或是有網路的環境時，系 統便會將資料上傳至後端資料庫。院內管理者可由資料庫查看訪視人員 回傳之紀錄，並進行新增、修改、刪除或查詢等動作。最後依需求將資料 庫中的資料進行統計運算，產生各種統計報表及圖表。
圖3、長期照顧資訊系統使用流程圖：外出訪視時需先下載資料至行動裝置中，待
有網路環境時系統會自動將資料上傳至後端資料庫
20
根據第壹章所提到，與合作醫院建置的長期照顧資訊系統會依據服 務內容而劃份成居家服務管理系統、送餐服務管理系統、家庭托顧管理系 統、日間照顧管理系統等子系統。由於這些子系統的功能都大同小異，且 表單與資料欄位繁多，因此系統皆使用模組化的方式來開發，以增加維護 效率。
長期照顧資訊系統的輸入控制項如文字方塊、下拉選單等，是以延續 張皓怡的研究論文[26]提出之基本元件模組化方式來建置。由於使用者端 主要是進行電子表單的新增與修改等操作，因此本研究也會參考上述之 基本元件模組化的建置方式，以表單常執行的資料新增、修改、顯示來開 發三種離線資料儲存元件。主要會透過 jQuery 選擇器抓取所有指定之 HTML <div>標籤中的輸入控制項，並將此區塊之欄位值進行批次新增、
修改至 Web SQL 資料庫，或是由 Web SQL 資料庫取得欄位值顯示於指
定之div 區塊的控制項中。將資料在Web SQL資料庫中儲存資料示意如 圖4，離線資料儲存元件的新增、修改、顯示函式所使用的參數內容如表
1，而各個參數的涵義對照如表 2。
21
圖4、資料儲存在瀏覽器提供的Web SQL資料庫示意圖：將資料儲存於Web SQL
資料庫中能讓使用者進行離線操作
表1、離線資料儲存元件所需參數
功
能 函式名稱 案
號 div id 資料表
欄位 資 料 值
自定義 條件
資 料 表
是否為最 後一張表 新
增 AutoInsert
修 改
AutoUpdate
SingleUpdate
顯
示 AutoLoad
表2、離線資料儲存元件參數涵義對照表
參數 說明
案號 欲進行新增、修改或顯示的個案號，為長期照顧資料表 的主鍵。
div id 要搜尋的區塊id值
資料表欄位 欲修改的資料表欄位名稱 資料值 欲更新至資料表欄位中的值 自定義條件 自定義的查詢條件(選填) 資料表 欲查詢的資料表名稱 是否為最後
一張表
布林值，因函式可執行多次，若為最後一張表則需填入 true，表示可以做後續頁面跳轉、重新整理等動作
22
(一) 資料新增元件
AutoInsert函式中共有4個參數，分別為案號、div id、資料表名稱及
是否為最後一張表，設置「是否為最後一張表」參數主要是因為同一張表 單之資料可能會新增或修改至不同資料庫之 table，因此函式可能會執行 多次，在此參數填入 true 表示此表為最後一張資料表，表示可以進行頁 面跳轉、重新整理等後續動作，使用範例如圖 5 所示，代表要新增此
Case_No 案號之個案在 ContendID_IADL 這個 div 的所有 input 值至
C1_8_IADL中。
圖5、資料新增元件使用範例
(二) 資料修改元件
AutoUpdate函式中共有 5個參數，分別為案號、div id、自定義條件、
資料表名稱、是否為最後一張表。第三個參數「自定義條件」是選填的項 目，若有額外指定更新條件才需填入。使用範例如圖6所示，代表要更新
此 Case_No 案號之個案在 ContendID_IADL 這個 div 的所有 input 值至
C1_8_IADL中，並遵遁Select_Where這個變數指定的 Where條件。
圖6、資料修改元件使用範例
欲修改資料除了可以使用AutoUpdate之外，也可以使用單一欄位資
23
料修改的 SingleUpdate 函式，欲更新任意資料至特定欄位值即可使用。
SingleUpdate函式中共有 6個參數，分別為案號、要更新的資料表欄位、
要更新的任意值、自定義條件、資料表名稱、是否為最後一張表。與
AutoUpdate 不同的是 SingleUpdate 可以將變數值更新至指定欄位如圖 7
表示將 Last_DTime 這項變數存至 F2_2_Diet_Send 資料表的 Remark0 欄
位中。
圖7、單一欄位資料修改元件使用範例
(三) 資料顯示元件
AutoLoad函式中共有4個參數，分別為案號、div id、自定義條件、
資料表名稱，使用範例如圖 8，表示要載入此 Case_No 案號之個案在
C1_8_IADL 資料表中欄位與 ContendID_IADL這個 div 中的元素 id 相同
的資料。
圖8、資料顯示元件使用範例
呼叫資料新增或修改元件函式後，系統會將篩選出的input 欄位與值 依照指定條件組成SQL語法中的Insert或 Update指令，這兩個指令分別 會讓資料新增或修改至Web SQL 資料庫中。若是呼叫資料顯示元件的函 式，系統則會將指定div區塊中的input 欄位依照指定的條件組成SQL語
24
法的Select 指令，此指令可由Web SQL資料庫查詢出欲顯示的檔案並載
入回表單控制項。離線資料儲存元件運作流程如圖9。
圖9、離線資料儲存元件運流程圖：透過離線資料儲存元件可對Web SQL執行新
增、修改、查詢語法
將資料儲存於瀏覽器的Web SQL能解決在貧乏的網路環境環境下無 法儲存資料的窘境，透過離線資料儲存元件能遍歷表單上的資料，並如同
操作後端 MS SQL 資料庫般，以 SQL指令對 Web SQL 進行新增、修改
或查詢。待處於有網路的環境時，長期照顧資訊系統中的資料同步模組便
會將Web SQL庫中的資料同步更新至後端MS SQL 中如圖10
25
圖10、離線資儲存元件架構圖：會將資料寫入於Web SQL資料庫，待有網路環境
時會透過資料同步模組將資料更新至後端，虛線部份為本研究之開發設計範圍
第三節 系統需求分析與設計
本節會先進行系統需求分析並定義實作範圍，接著再進行系統架構 設計及系統功能規劃。
(一) 需求分析
如文獻探討所述，電子地圖及適地性服務在各領域中皆有許多應用，
例如將地圖與資料混搭產生互動式地圖幫助使用者進行分析及決策、利 用行動裝置進行位置監測來了解使用者活動軌跡，並提供其所在地區的 相關資訊、導航服務等。除參考以上應用外，本研究會承襲先前與開發合 作醫院開發長期照顧系統之經驗，從2015年2月1日起便開始固定進行
26
每週視訊會議以及使用 E-mail 討論需求，研究團隊也會實際到合作醫院 進行面對面需求訪談，院方主管也會北上來實驗室進行面對面的討論。本 研究於2016年8月1日及9月5日在院方人員開車帶領之下實際至各地 進行打卡功能測試、2017年2月15 日更跟車參與送餐服務。最後經由實 地探訪來從中瞭解長期照顧對電子地圖及適地性服務的需求。
1. 地圖及適地性服務導入長期照顧資訊系統之範圍
本研究旨在於將電子地圖及適地性服務導入長期照顧資訊系統中，
與合作醫院進行開發的長期照顧資訊系統目前已上線使用的有居家服務 與送餐服務子系統。因此本研究在導入長期照顧資訊系統的部份會以兩 個子系統為例，達到實際導入之目的及具體應用。
2. 定位資訊記錄範圍
在與合作醫院的訪談過程中，院方提及送餐員在進行送餐及提供關 懷服務的同時，可能會有問候年長者的時間太久導致延遲後續送餐的情 形，且日後也不易檢討送餐延遲原因。因此，不僅限於送餐服務，當訪視 人員外出服務且填寫服務紀錄單的同時，若能一併記錄當下的時間及經 緯度位置，不但能讓管理人員在必要時可以做臨時調度，也方便進行與服 務地點的比對。
本研究也藉由實地探訪來了解合作醫院外出訪視的流程，對於是否
27
設計持續記錄定位資訊的功能，經由與醫院討論後，認為現有的訪視流程 若持續記錄定位資訊會造成行動裝置電力與行動數據傳輸量不必要的耗 損，因此本研究只記錄服務當下定位的位置資訊。以送餐服務與居家服務 為例，送餐服務為當下送餐交付時便需要記錄時間及定位資訊；而居家服 務則是會在記錄服務時間起、迄的當下皆需要一併記錄定位資訊。
3. 統計地圖範圍
本研究整理合作醫院長期照顧系統中居家服務及送餐服務表單，進 而篩選出當中與地區相關且可使用地圖輔助呈現之統計報表。分析結果 如表3。
表3、合作醫院長期照顧系統中與地域相關之統計報表
報表名稱 可呈現之統計資訊
F1-11 居家服務個案管理基
本資料表 各區域之個案人數統計
F1-13 服務費用明細 各區域之服務時數總計、補助金額總計
F1-22 分區域服務狀態 各區域之服務人數、時數總計
F2-7送餐服務個案管理基本
資料表 各區域之個案人數統計
F2-10 費用明細表 各區域之餐數總計、補助金額總計
F2-11 服務狀態 各區域之服務人數、時數總計
C1-25統計資料
各區域之收案人數統計、結案人數統 計、個管人數統計、失能程度總計、平 均照顧月數統計、結案照顧月數統計
C1-28-申訴統計總表 各區域之申訴量統計
28
(二) 架構設計
合作醫院之長期照顧資訊系統是以Web App 的方式設計開發，方便 於行動裝置中使用，訪視人員或管理人員可透過各種作業系統平台的瀏 覽器來進行系統操作。因此本研究也會使用 HTML5 搭配 jQuery Mobile 函式庫來進行跨平台的應用程式系統開發。本小節會針對使用者角色、系 統功能及系統架構作說明。
1. 使用者角色
由於合作醫院目前上線使用的系統為居家服務及送餐服務，因此本 研究所開發之地圖及定位功能模組便以導入此兩個子系統為例。有鑑於 此，本系統的主要使用者即為居家服務員、送餐服務員、督導員及主任，
這些使用者在系統中可依身分區分為訪視人員及管理人員。為了避免使 用者身份太多造成說明不易，本研究將會以上述兩個使用者角色來統稱 不同使用者。如表 4 所示，訪視人員包含需外出服務的居家服務員與外 出送餐的送餐服務員；管理人員則包含可查看訪視人員資料、負責管理訪 視人員的督導員與主任。
表4、使用者角色定義表
使用者角色 使用者身份 訪視人員 居家服務員、送餐服務員 管理人員 督導員、主任
29
2. 系統功能
在上一小節有提及合作醫院目前上線使用的系統為居家服務及送餐 服務，因此本研究建置之地圖及定位功能模組會以此兩個子系統為主進 行實際導入，導入後的長期照顧資訊系統功能如圖11所示，地圖及定 位模組功能圖如圖12，根據文獻探討及需求分析，本研究將系統分為五 個模組，包括經緯度轉換模組、裝置定位模組、地圖點位模組、路徑規 劃模組以及統計地圖模組，以下將介紹系統使用案例圖及各模組功能。
圖11、導入地圖及定位功能後的長期照顧資訊系統功能圖：本研究會建立地圖及定
位功能模組，並應用於送餐服務與居家服務中
30
圖12、地圖及定位模組功能圖
地圖及定位功能模組的使用者案例圖如圖13所示，訪視人員可進行 規劃路徑及定位目前位置，而規劃路徑服務中也包括了計算距離的功 能。管理人員除了不需定位目前位置之外，上述功能皆可使用。此外，
管理人員還多了查看訪視人員位置、查看統計地圖及經緯度轉換的功能 可使用。查看訪視位置功能必須由訪視人員先進行位置定位並儲存後，
管理人員才能進行查看。
圖13、使用案例圖：使用者分為訪視人員與管理人員
31
經緯度轉換
若要做訪視人員外出服務的定位比對及路徑規劃，個案地址經緯度 會是相當重要的資訊，若經緯度資訊不正確，便會影響到上述訪視定位之 比對，甚至是路徑規劃的正確性。因此，本模組利用內政部地理資訊圖資 雲服務平台(TGOS)提供之TGOS API 的全國門牌地址定位服務來取得個 案地址之經緯度資訊。圖資雲的全國門牌位置資料庫有 800 萬的臺灣門 牌位置資料，因此在個案地址經緯度上比起利用 Google 提供的 Google Maps Geocoding API轉換更精確[69]。
裝置定位
裝置定位模組主要用來定位訪視人員外出服務時的位址資訊，此模
組使用HTML5 Geolocation API 來進行裝置之定位，Geolocation API 是由
W3C定義的 API規範，Geolocation API 會從行動裝置的GPS 來獲取地理
位置的經緯度資訊，若是沒有搭載GPS晶片的裝置(如：桌上型電腦)，也 可根據網際網路服務供應商(Internet Service Provider，ISP)分配之IP來推 估出粗略的地理位置，但使用此方式可能會有些誤差，與實際位置最遠差 距可達數公里甚至數十公里[70]。
定位精準度主要視行動裝置搭載的 GPS 設備好壞而定，但因各瀏覽 器定位方式有所不同，因此即使是同一設備，不同瀏覽器的定位結果可能
32
也會大不相同。Geolocation API在各大瀏覽器間都有支援，支援的瀏覽器 包括Chrome、Internet Explorer / Edge、Firefox、Safari以及 Opera。值得 注意的是，Chrome 為了保護使用者的位置資訊，從 2016 年 4 月發佈的 版本號 50 開始，Geolocation API 僅限於如 HTTPS 的安全環境下使用，
在未加密的瀏覽狀態下如HTTP 已無法使用[71]。
地圖點位
利用地圖點位方式，能讓管理人員查看個案住址分佈狀況以及訪視 人員的服務位置。此模組主要使用Google Maps Javascirpt API 來做地圖 的呈現，Google Maps 除了有詳細的道路資訊外，也能自定義點位符號 (Maker)，可利用不同點位符號將個案住址及訪視人員定位資訊做區隔呈 現，方便查看。
路徑規劃
路徑規劃模組可以產生至個案家的路線圖，若是需要在一定時間內 訪問不同地點的服務，像是送餐服務等，也可以進行多點間的路徑規劃。
此模組主要透過 Google Maps Javascirpt API中的 Directions service 來進 行路線規劃服務，除了能產生訪視路線之外也能獲取行駛距離與時間，因 此也可以利用此模組計算各點之間的距離與總哩程數。
33
統計地圖
本研究開發的統計地圖模組是以面量圖(區域密度圖)進行呈現，會將 資料按大小分等，再將等級大小以由深至淺的顏色填入每一鄉鎮市區，可 以明顯表現每一區域統計資料的差異。
在建置統計地圖功能前，本研究會先利用 QGIS軟體將內政部國土測 繪中心提供之鄉鎮市區界線圖資以各縣市為單位對每個鄉鎮市區進行
GeoJSON格式之轉換，GeoJSON 是一種描述地理資訊的格式，有著輕便
及可閱讀之特性，因此為在網際網路分享地理空間資料的常用標準[45]。
QGIS全名為Quantum GIS，是一個開源且免費的地理資訊系統，提供了
許多 GIS 常用的功能。內政部國土測繪中心提供之鄉鎮市區界線圖資為
ESRI Shapefile格式，Shapefile(Shp)屬於一種向量圖形格式，它能夠保存
幾何圖形的位置及相關屬性。該種文件格式是由多個文件組成的主要包 括.shp：主要檔案，用於保存元素的幾何實體、.shx：索引檔案，用於保 存幾何實體索引、.dbf： dBase表格檔案，用於保存關於元素的屬性資訊 [72]。
本研究使用QGIS將鄉鎮市區界線圖資以表格檢視並且進行篩選、排 序，如圖14。接著將以縣市為單位篩選過後的鄉鎮市區存成 GeoJSON格 式如圖 15 所示，每個顏色都是獨立的縣市 GeoJSON 檔案，之後便可將
34
此檔案套入 Google Maps API 中利用資料圖層方式來將呈現鄉鎮市區邊 界及統計資訊。將鄉鎮市區邊界繪製好後，只要匯入統計資料至此模組，
即可將縣市之鄉鎮市區的統計資訊呈現於地圖中。
圖14、以表格檢視鄉鎮市區界線圖資
35
圖15、不同色塊為篩選過後的獨立縣市
3. 系統架構
圖16為地圖及定位功能模組之系統架構圖，圖中虛線的部份為本研 究之開發設計範圍。使用者端的各個模組皆可為長期照顧資訊系統所使 用。若在長期照顧資訊系統表單中呼叫地圖及定位功能的模組如裝置定 位模組與經緯度轉換模組時，模組便會將產生的資料回傳給長期照顧資 訊系統，因此回傳之資料即會透過長期照顧系統本身的儲存機制來儲存。
但若要產生統計地圖、路徑規劃，甚至是批次進行經緯度轉換等需要由地 圖及定位功能模組來查詢或更新長期照顧資訊系統資料庫的情形，就必
36
須透過後端 Web Services 才能進行長期照顧資訊系統資料庫的讀寫。以 下將分別詳述地圖及定位功能模組使用者端的各個模組及伺服器端的設 計內容。
圖16、系統架構圖，虛線部份為本研究之開發設計範圍
伺服器端
地圖及定位功能模組伺服器端是使用 ASP.NET C#的技術建置 Web Services，負責管理地圖及定位功能的各模組與長期照顧資訊系統間的資
37
料交換，能讓使用者端進行與長期照顧資訊系統資料庫的查詢與上傳。
Web Services主要提供個案資料查詢、經緯度欄位更新以及統計報表的查
詢與計算服務，使用者可依不同需求來連結不同的Web Services服務。考 慮到輕量且易讀的特性，本研究所建置之 Web Services 中所有服務的結 果皆以JSON字串格式回傳。JSON全名為JavaScript Object Notation，是 一種輕量級的資料交換格式。不但容易讓人閱讀及撰寫，機器也能輕易解 析和產生此格式[73]。
使用者端
A.經緯度轉換
經緯度轉換模組有資料查詢、JSON解析、資料更新、經緯度轉換四 種功能，如圖17，其中經緯度轉換功能是透過呼叫 TGOS API 來進行住 址與經緯度的轉換。經緯度轉換模組架構圖如圖 18，此模組有兩種使用 方式，第一種是將模組載入至長期照顧資訊系統的表單中，呼叫經緯度轉 換模組將住址參數傳送至經緯度轉換功能產生經緯度座標，並將此座標 回傳至長期照顧系統表單中。第二種使用方式是透過使用者介面將批次 地址進行經緯度轉換。可經由使用者介面呼叫伺服器端的Web Services查 詢長期照顧系統資料庫中使用者所負責之個案。Web Services會將查詢到 的內容以 JSON 格式回傳如圖 19。之後透過 JSON 解析功能將 JSON 格
38
式解析，取出住址傳送至經緯度轉換功能，得到回傳之經緯度資訊後，即 利用資料更新功能，透過 Web Services 將經緯度資訊新增至長期照顧資 訊系統資料庫中。
圖17、經緯度轉換模組功能圖
圖18、經緯度轉換模組架構圖，虛線部份為本研究之開發設計範圍
39
圖19、經緯度轉換模組呼叫Web Services回傳之JSON格式
經緯度轉換功能流程圖如圖20，只要輸入地址，即可經由TGOS API 進行經緯度轉換，當查詢到此地址的經緯度座標時，便會輸出此座標資訊，
能讓其他模組做後續應用；反之，若查無經緯度座標可能是因為地址登打 錯誤或不夠詳細，此時便會輸出「無資料」的字串。
40
圖20、經緯度轉換功能流程圖
B.裝置定位
圖21為裝置定位模組架構圖，此模組主要是在長期照顧資訊系統表 單中使用，僅有裝置定位一個功能，此功能是呼叫 HTML5 Geolocation API並回傳定位結果。
裝置定位功能流程圖如圖22，若使用者的行動裝置不支援地理定位，
那麼此功能便會自動結束。若行動裝置支援地理定位，此功能便會進行裝
41
置定位並輸出定位資訊，供後續模組做使用。
圖21、裝置定位模組架構圖，虛線部份為本研究之開發設計範圍
圖22、裝置定位功能流程圖
C.地圖點位
地圖點位模組有資料查詢、JSON解析、地圖點位三種功能，如
42
圖23。圖24為地圖點位模組架構圖，可經由使用者介面使用資料查 詢功能呼叫伺服器端的 Web Services 查詢長期照顧資訊系統資料庫 中的個案住址或訪視人員定位資訊，查詢完成後 Web Services 會回
傳一個 JSON 字串如圖 25，利用 JSON 解析功能可解析此字串並呼
叫地圖點位功能來將座標點位於地圖中。
圖23、地圖點位模組功能圖
圖24、地圖點位模組架構圖，虛線部份為本研究之開發設計範圍
43
圖25、地圖點位模組呼叫Web Services回傳之JSON格式
地圖點位功能是使用Google Maps JavaScript API 來建置，因此必需
在 HTML5 頁面中加入一個名為「map」的 div 元素來容納地圖，並在
<script>標記載入 Google Maps JavaScript API，最後加入地圖物件。載入 地圖的基本範例如表5。
表5、載入Google Maps JavaScript API的基本程式碼範例[13]
<!DOCTYPE html>
<html>
<head>
<title>Simple Map</title>
<meta name="viewport" content="initial-scale=1.0">
<meta charset="utf-8">
</head>
<body>
<div id="map"></div>
<script>
var map;
function initMap() {
map = new google.maps.Map(document.getElementById('map'), { center: {lat: 25.117, lng: 121.521},
zoom: 10
44 });
}
</script>
<script src="https://maps.googleapis.com/maps/api/js?key=YOUR_API_KEY&call back=initMap" async defer></script>
</body>
</html>
基本地圖載入完成後，便可使用地圖點位功能，此功能需要輸入4個 參數，分別為經緯度座標、地圖物件、欲顯示之資訊及標記類型，表6為 地圖點位功能所需參數及說明。地圖點位功能流程圖如圖 26，輸入參數 後系統會設置欲顯示之資訊及定位標記，最後呈現於地圖中。
表6、地圖點位模組所需參數及說明
參數 說明
經緯度座標 以逗號分割的經度及緯度，如：25.117549,121.521347 地圖物件 被指派給Map 物件的變數，如表5中的map變數。
欲顯示之資訊 點擊標記要顯示的文字，可使用HTML格式。
標記類型 欲顯示何種標記圖示，分為「HOME」：房屋圖示，
與「CHECKIN」：定位點圖示
45
圖26、地圖點位功能流程圖
D.路徑規劃
路徑規劃模組有資料查詢、JSON解析與路徑規劃三種功能，如圖27。 圖28為路徑規劃模組架構圖，在使用者介面中可透過資料查詢功能呼叫
伺服器端 Web Services 由長期照顧資訊系統資料庫查詢個案住址或訪視
人員定位資訊，查詢完成後Web Services會回傳一個 JSON字串，回傳之
46
資料型態可參考圖 25。取得字串後，利用 JSON 解析功能即可解析此字 串並透過路徑規劃功能來進行路線規劃與顯示路線，並呼叫地圖點位模 組的地圖點位功能，將座標點位於地圖中。
路徑規劃功能是使用Google Maps JavaScript API 來建置，因此與地 圖點位模組相同，需在HTML 頁面載入地圖後方可使用。
圖27、路徑規劃模組功能圖
圖28、路徑規劃模組架構圖，虛線部份為本研究之開發設計範圍
路徑規劃功能流程圖如圖 29，必需輸入至少兩個經緯度座標做為起 點及終點，利用Google Maps JavaScirpt的Directions service 進行路線規 劃後，若沒有要計算行駛距離，便直接於地圖呈現路徑規劃結果；若有要
47
計算行駛距離，則會輸出距離與呈現路徑規劃結果。
圖29、路徑規劃模組流程圖
E.統計地圖
統計地圖模組有資料查詢、JSON 解析、URL 產生、URL 解析與資
48
料圖層產生五種功能如圖30。圖31 為統計地圖模組架構圖，使用者先由 長期照顧資訊系統的統計報表進行統計查詢後，統計報表頁面會透過統 計地圖模組的 URL 產生功能產生一個 URL 超連結，此超連結包含使用 者欲查詢的年份以及統計報表代號，點擊此超連結即可利用GET傳值方 式來跨頁面地將參數傳送至統計地圖模組中。GET 是 HTTP 協定規範中 的 一 種 請 求 方 法 ， 在 URL 後 加 入 變 數 名 和 值 即 可 傳 值 。 以 網 址
「staticMap.html?y=2017&rpt=F2_11rpt」為例，問號後面代表變數名稱與 值，可用「&」連結多個參數。此範例表示欲傳的值為變數 y=2017 與變 數rpt=F2_11rpt。
進入統計地圖模組的使用者介面後，URL解析功能會先解析 URL並 取得當中傳來的年份與報表代號的值，接著資料查詢功能便會呼叫伺服
器端Web Services 選擇對應的SQL資料庫語法對長期照顧資訊系統資料
庫進行查詢，接著會利用與報表代號對應的統計報表計算公式進行統計 資料運算，運算過後Web Services會以 JSON格式回傳統計結果，回傳之 JSON格式範例如圖32。透過JSON 解析功能即可解析此字串，並利用資 料圖層產生功能將統計資訊載入至對應的鄉鎮市區中，並於地圖上呈現。
49
圖30、統計地圖模組功能圖
圖31、統計地圖模組架構圖，虛線部份為本研究之開發設計範圍
