第五章 系統開發與實作
第一節 行動應用程式
國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
42
第六章 系統測試
系統實作完成後，本章將會載入健保資料進行系統測試，以下詳述系統測試之過程 及結果。
第一節 行動應用程式
程式開始執行畫面如下左圖所示，登入成功後會顯示註冊成功，如下右圖所示。做 為控管資訊的功能，在這裡需要輸入使用者的員工帳號及密碼，連同裝置唯一識別碼向 後端伺服器進行註冊程序，以確保連結內部資料庫的安全性。右下圖上面的跑馬燈是程 式進行加載時的狀態顯示，會進行網路連結確認、資料連結檢查等步驟。
Figure 30登入畫面 資料來源：本研究整理
登入成功後會進入程式首頁，並且儲存帳號資訊，當關閉程式，再從新開啟時，無 需再次進入登入頁面，直接跳轉到首頁畫面，同時顯現已註冊的提示，如同Figure 31所 示。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
43
Figure 31程式首頁 資料來源：本研究整理
當訊息來的時候，會在裝置系統列上顯現，並且藉由震動以及畫面鎖定引起使用者 的注意，期許使用者能在報表生成後的第一時間取得報表，如同下圖所示，會顯示由中 央健保署來的通知，並且告知推播內容是幾月分析報表已完成。
Figure 32接收到推播訊息 資料來源：本研究整理
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
44
點擊訊息將會直接啟動程式，並且呈現推播通知內的分析報表於行動應用程式中，
如同下圖所示。
Figure 33報表呈現於平板 資料來源：本研究整理
第二節 健保異常申報醫院之分析
本研究將針對1999年至2003年5年間，紀錄在案被停止合約的醫院和診所進行分析。
一、 描述性統計
下表（Table 6）的資料為行政院衛生福利部中央健康保險署2014年的公開統計資料，
因為本研究由國衛院取得的資料只有1999年至2003年的5年健保資料，因此下表也只擷 取該5年資料。5年之中，2000年的違規醫事機構相較於前年有大幅度的降低，但是往後 幾年卻又有故態復萌的跡象，2003更是首度超越了1999年的違規數量。
Table 6全民健康保險特約醫事服務機構查處199年至2003年統計表
醫院評鑑等級 1999年 2000年 2001年 2002年 2003年
醫學中心 25 18 10 16 25
區域醫院 81 31 41 71 100
地區醫院 277 143 110 230 323
‧
（Data Cube）及維度表（Dimension table），事實資料表的資料依據資料倉儲建置所產 生的資料，維度資料表依照各變數之變數設定水平建置，本研究共建置1個資料立方體，
以及5個維度，如下圖（Figure 34）所示，醫療機構事實資料表包含，類別序號、型態 序號、評鑑序號、日期序號和地區序號等５個外來鍵，分別聯到五個各自個維度表。資 料立方體建置好後即可以拖拉維度或量值(即是所謂的變數)的方式作多維度的交叉分析。
本研究之多維分析係利用此建構好的資料立方體，透過Tableau進行視覺化圖表分析。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
46
Figure 34 醫事機機構事實資料表 資料來源：本研究整理 三、 地理區域性分析
Figure 35以所屬管轄區域分析 資料來源：本研究整理
健保局可以根據地區這一維度分析進行各區分局的管理狀況審查，也可以在電腦數 據抽樣上加權，不一定是單純的隨機抽樣。根據上圖所示，台北分局的違規醫事機構是
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
47
最多的，台北分局管轄的區域包含北北基、宜蘭縣及金馬，單以雙北市而言，其擁有占 全台將近1/3的醫院門診數量，雖說如此但是５年的違規醫院，還是占總數量的將近一半，
這一結果顯示台北分局對其所轄的行政區域在監督上有其不良之處，導致違規事件頻傳，
此外，根據統計，新北市在台北分局的違規總數中占了一半以上，是全台居冠，每年的 違規數量也皆是各縣市中最多的，詳見下表。
Table 7新北市1999年至2003年違規醫院數量
年份 １９９９ ２０００ ２００１ ２００２ ２００３ 新北市違規
醫院 ９ ４ ４ ２ ３
資料來源：本研究整理
北區分局的違規醫事機構５年下來只有４間，雖然東區分局只有兩間，但是根據醫 院數量及行政區數量，明顯是北區分局更優良，這其中就有其研究價值，北區分局與台 北分局兩者之間的做法友和不同之處，兩者之間差了７倍有餘。以優良的管理範例來督 導其它各分局，應能有治標的效果。
四、 地圖分析報表
Figure 36地圖分析報表 資料來源：本研究整理
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
48
上圖（Figure 36）的地圖報表分為四個部份，左上地圖是標示各縣市的違規醫院數 量，各點的顏色表示違規的數量，圖例如同右上所顯示的，顏色越深，違規的醫事機構 數量就越多；左下是各分局的統計數據，點選各分局，會在左上的地圖篩選顯示轄下行 政區，如同下圖（Figure 37）所示;右中則是違規醫院列表，這張列表是透過左上的地圖 進行篩選呈現，如同下圖（Figure 38）所示，點擊地圖上的台北市，列表就會呈現5年 內違規的醫院列表。
Figure 37以中區分局為例顯示所轄行政區 資料來源：本研究整理
Figure 38已台北市為例顯示醫院列表 資料來源：本研究整理
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
49
如果點擊醫院列表中的任意一家醫院，將可以開啟Google 地圖，自動標誌該醫院的 所在，如下圖（Figure 39）所示。如此一來，基層的查核人員，未來可以依照當月份的 可疑醫事機構列表，輕鬆的得知該院所的地理位置。
此外，可以藉由右下方的過濾維度，進行多維度的分析，多維度的分析有助於分析 人員得知更多得事情，從Figure 38可以得知台北市大多都是基層診所出問題，若是加上 醫院型態進行分析，可以發現一般診所跟牙醫各占一半的數量。有些地區則有可能是地 區醫院有問題，基層院所沒有異常，如同下圖（Figure 40）所示。
Figure 39以台北市XX牙醫為例 資料來源：本研究整理
Figure 40以形態別與地區進行多維度分析 資料來源：本研究整理
‧
84年3~12月 85年1~12月 86年1~12月 87年1~12月 88年1~12月 89年1~12月 90年1~12月 91年1~12月 92年1~12月 93年1~12月 94年1~12月 95年1~12月 96年1~12月 97年1~12月 98年1~12月 99年1~12月 100年1~12月 101年1~12月 102年1~12月
各年違規醫事機構總計
數量
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
51
對於雲端資料庫作為資料來源，本研究在進行資料來源建立以及資料萃取的花費時 間，醫事機構基本檔25~30分鐘，門診處方及明細檔需要50~60分鐘不等，而使用關聯式 資料庫單單一個醫事機構基本檔則要7~8小時[41]，才能整理萃取完成。這是因為資料庫 每秒可處理的資料數量有一定的限制，在面臨連續大量的資料讀取或是寫入的時候，
MySQL資料庫就會面臨瓶頸，導致其需要花費大量的時間，然而 HBase根據文獻探討提 及的設計原理， HBase 會將資料先暫存於記憶體緩衝區中，因此，在連續大量資料寫入 時，透過分散式運算的機制，可以減少單一磁碟I/O的動作。
最後則是行動應用，在使用族群為飽和的狀態之下， GCM的推播功能並沒有拖延傳 遞訊息，可達到即時推播的功效。 此外，透過行動裝置呈現商業分析報表，平版的呈現 效果明顯優於手機，手機畫面過於狹小，在呈現報表會需要使用者拖拉畫面，而對於節 點的點擊也較於不易，因此對於觀看報表造成妨礙，如下圖所示，使用者無法一目了然 的看到整個儀表板，必須要自型前後滑動螢幕才能看見其他部份，這也是將服務透過行 動裝置呈現所容易遭受的問題。
Figure 42報表呈現於手機 資料來源：本研究整理
‧
查詢到該資料在哪之後，再進行交叉比對，找到相對應關鍵值（Key Value）的資料，
如此就可以大幅縮小查詢的母體，查詢時間自然較為快速。
‧
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
54
整體來說，新的商業智慧運作模式可以提供使用者解決巨量資料對於商業智慧帶來 的問題，提供了更好的時效性，使用者可以藉此更快掌握先機。並且透過行動應用程式 給予另一種接收途徑，使用者不一定需要電腦才能得知分析結果，經由推播訊息的通知，
可以立即在行動裝置上收看到分析報表，做出即時的反應。
第二節 未來展望
有關商業智慧中雲端行動的需求日益增加，更多的企業需要的是從巨量資料中挖掘 更多有價值的資訊，本研究僅初步提出雲端資料庫搭配行動應用的商業智慧的系統架構，
仍有需要加強改進的地方，因此提出幾個未來值得探討研究的方向：
1. 目前在本研究中方面，除了本身龐大的健保資料外，只有引用醫院診所的地理位 置資料，在分析的時候，若使用社群網路的公眾訊息，如臉書、推特等，常試透 過民眾對於醫院的留言評價，經由斷詞斷句及情感傾向判定該可疑醫事機構是否 有可能違規，加入分析維度，以此增進報表的內容。
2. 在行動應用的方面，本研究嘗試透過平板電腦及手機兩種行動裝置呈現，但是在 呈現方面會因為螢幕大小的因素，使用者有相反的體驗，本研究的行動應用程式 在平板上有較好的效果。尚無法因為接收的裝置不同給予不同的呈現效果，未來 可以有兩種改進辦法，一種是根據不同的裝置類型，開發不同的行動應用程式，
手機方面可以透過分頁的功能縮減報表大小；另一種是在報表方面輸出兩種版本，
在推播訊息時，根據裝置類型推播不同的分析報表。
3. 承上第二點，行動裝置的管理，企業內部的商業智慧存放企業重要資料，將這些 資料開放給行動裝置存取也增加重要資料外洩的風險，因此一直是管理人所憂心 且不願開放的因素。本研究僅透過裝置識別碼與員工帳號進行資訊控管，如果使 用者遺失手機，還是有可能造成資料的外洩，因此安全保護機制可能需要持續新 增。
‧
[1]. Andrew Borg, David White, “Mobile BI,” Aberdeen Group ,Dec 2010.
[2]. Bell, R. & Todd, G., “Information Management Services: Overview of Services.”
Accenture, s.l., April 2007
[3]. Bowen, F., “How SOA can ease your move to cloud computing,” IBM,
http://www-01.ibm.com/software/solutions/soa/newsletter/nov09/article_soaandcloud.ht ml
[4]. Chris Eaton, Dirk deRoos, Tom Deutsch, George Lapis, Paul Zikopoulos, “Understanding Big Data-Analytics for Enterprise Class Hadoop and Streaming Data,” McGraw Hill, 2012.
[5]. Chuck Lam, “Hadoop in Action,” Manning Publications Co. Greenwich, CT, USA,2010.
[6]. CIO Insight, “Mobility Moves From Productivity to Strategy,” CIO Insight, Issue 56, 2005, pp. 61-69.
[7]. Cisco, “Cisco Visual Networking Index: Global Mobile Data Traffic Forecast Update,
[7]. Cisco, “Cisco Visual Networking Index: Global Mobile Data Traffic Forecast Update,