第五章 系統開發與實作
第三節 行動應用程式開發
二、 推播訊息的接收
國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
37
Figure 23蒐集資訊準備執行認證模組 資料來源：本研究整理
Figure 24 身分驗證錯誤，中止註冊程序 資料來源：本研究整理
二、 推播訊息的接收
註冊完成的行動裝置即可以接收到傳播模組傳來的訊息，因使在程式這邊需要進行 訊息的接收，重點在於onMessage()以generateNotification()及兩個功能，onMessage()會將 傳來的訊息(JSON)透過Bundle進行拆解傳送給generateNotification()運用，如果程式正在 運行，變即刻顯示提式通知；generateNotification()則是設定當行動裝置接收到訊息時需 要執行的事項，包含需要啟動的Activity，訊息的顯示標題及內容以及行動裝置的鈴聲震 動鎖定畫面與否等三大事項，確保使用者能在第一時間知曉訊息的到來，當使用者點擊 訊息便啟動程式並呈現分析報表，詳見下圖。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
38
Figure 25訊息的接收與處理 資料來源：本研究整理 三、 分析報表的呈現
當訊息被點擊，程式被啟動，先按照流程檢查使用者資訊，此時因為訊息傳送的內 容，因此會先跳轉到新的分析報表，而非原本的首頁，因為是用PhoneGap套件，所以對 於頁面的呈現比起原生網頁能更快載入完成。下圖所示的程式是用來判斷啟動程式是透 過訊息啟動，或是直接啟動，兩者會前往不同的畫面。
Figure 26啟動程式後的首選畫面 資料來源：本研究整理
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
39
第四節 推播模組之實作
當有新的報表產生時，推播模組會進行訊息的推播程序，其運行過程首先是新檔案 的抓取，接著檢索有註冊的行動裝置並且編寫訊息內容，最後發送至Google伺服器等待 推播。由於需要儲存必要資料，因此透過MYSQL進行資料管理，資料庫部分設計的實 體關係圖（Entity Relationship Diagram，ERD）如下圖所示（Figure 27）。按照GCM需 求 的 資 訊 ， 訊 息 內 容 的 編 寫 ， 所 用 到 的 實 體 包 括 gcm_bifile 、 push_android_regid、
push_queue_android以及前段認證模組用到的gcm_employee。
Figure 27實體關係圖 資料來源：本研究整
gcm_bifile是用來儲存新增的分析報表資訊，包含檔案名稱，新增時間及檔案位置，
此資料表主要是為了編寫訊息內容，藉由欄位bifile_push，判斷是否該檔案是否以向使 用 者 發 送 過 推 播 訊 息 。 接 著 push_android_regid用來儲存眾多註冊的ID ， 透 過 欄 位 regid_vaild來管理RegID，藉由Google伺服回傳的推播結果，適時的將因解除安裝程式而 導致推播失敗的ID註銷。由於Google伺服器一次只能向最多1000部裝置推播訊息，因此 設置push_queue_android這張用來等待推播的排程資料表，藉由欄位pqa_time_sent來檢索 何 筆 訊 息 尚 未 被 傳 遞 ， 也 因 如 此 所 以 此 表 包 含 了 傳 遞 目 的 地 RegID 及 推 播 內 容 pqa_payload兩個欄位。最後的gcm_employee則是儲存使用者帳號資訊及申請的行動裝置 唯一識別碼。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
40
透過windows系統排程，定時啟動gcm_checkfile.php，檢查有無新增的檔案，若結果 是有，則將按照下述格式編寫訊息內容：＂＄bifile_name於$bifile_time已分析完成！＂，
連同檔案位置（$bifile_adress）以及篩選出註冊在表單上的行動裝置RegID，新增進入 push_queue_android表單中，通過android_push.php開始進行排程傳遞。
android_push.php負責從表單中檢索尚未傳遞的訊息安排進行傳送，在這裡因為有傳 遞數量的限制，因此在檢索的SQL語法，必須加上Limit限制一次傳送給Google 伺服器 的數量，如下圖所示。並且接收Google 伺服氣回傳的JSON報告，對RegID進行管理以及 紀錄傳送結果。
Figure 28 推播訊息排程 資料來源：本研究整理
透過上圖粗框所示，實作一GCM class() ，負責傳送，傳送流程很簡單的說，兩者的 關係就像是前者是遊覽車，一次只能載一定數量的乘客，GCM class()就是司機，乘客攜 載著RegID（搭飛機必要的機票）、message及url（行李），前往機場（Google 伺服器），
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
41
準備飛往各自的目的地。如果RegID是搭飛機必要的機票，那SenderID就是航空公司的 營業證照，透過向Google Developeg 申請，是發送訊息的必要金鑰，上述的過程如同下 圖（Figure 29）所示。
Figure 29訊息推播 資料來源：本研究整理
第五節 分析報表製作
本研究採用Tableau8.2進行分析報表製作，與其他商業智慧軟體相較，優先選擇的原 因是其提供可鑲刊至網頁的發布選項，以一份商業智慧製作的儀表分析報告，其檔案都 有幾10MB以上，對於行動應用程式來說，並非是一好的決定，想要使用者能輕鬆快速 的接收使用報表，能方便輸出成幾百KB的商業智慧軟體是，結合行動應用的好選擇。
另外，Tableau是一家專門開發商業智慧軟體的公司，其首重數據資料的可視覺化，提供 無基礎的人容易上手的操作環境，而其缺點則在尚且屬於商業智慧軟體，未達到平台的 環境，而且面對巨量資料的應對上，雖然提供了以Hive及HBase做為資料來源，但其分 析報表的數據來源尚限制在1,000,000 Rows，但是對於學術研究以及單純製作分析報表 的需求來說，其實問題不大。
‧ 國
立 政 治 大 學
‧
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）所示。如此一來，基層的查核人員，未來可以依照當月份的
如果點擊醫院列表中的任意一家醫院，將可以開啟Google 地圖，自動標誌該醫院的 所在，如下圖（Figure 39）所示。如此一來，基層的查核人員，未來可以依照當月份的