不好意思比較晚開始，我們一向準時開始，但因為上一場會比較晚。

這一個會議其實是滿早以前就約的，我剛剛看了一下簡報，其實我們現在的實際狀況比那時在約這場會的時候還要好。

我們今天的紀錄原則跟任何我召集的會議是一樣的，也就是我們會做成逐字的紀錄，簡報裡面如果有覺得不適合公開，又或者是講得過程覺得不適合公開的部分，大家會有十個工作天的時間，都會收到一個網址，可以上去改任何自己發言的部分，甚至整段拿掉都可以，我們會在十個工作天之後對外公開。

同樣的道理，各位的簡報我們瞭解是內參的性質，但十個工作天之後，也麻煩有可以公開的部分，或者是部分公開的部分，麻煩出一個公開版的簡報，我們會跟逐字稿一起公開，這樣子外面的朋友才比較知道我們在講什麼，這個是今天的紀錄原則，我們就不多耽擱，直接進入報告。

主席、各位與會先進，大家好，我代表衛福部社會救助及社工司針對「避難收容處所人員管理通報」進行以下簡報。

簡報大綱的部分，請主席跟所有的長官參閱。

避難收容處所平時及災時的管理規定，我們會針對平時跟災時來作兩個部分的說明：

第一，我們除了要建立平常避難收容處所的資料，包括地方政府會調查一些先行的安全地區，針對避難收容處所的資料，有關於要避開潛勢區域的部分，要先作確認跟定期更新。

地方政府在相關的網站都會定期更新所管避難收容處所之資訊。

有關於老人或者是特殊個案的部分，也會請地方上老人長照機構跟收容機構，針對需求的部分來作安置，確定整個安置的品質上是可以因應災時的需要。

在平時的部分，我們會針對收容空間的整備，包括災民要進駐之前，要確認場地消毒跟隔間的工作，比如像日常生活用品，甚至考量到嬰幼兒及空間等等的物資準備。

平時的部分，我們做了這一些整備工作，我們也會做災時的管理，我們首先依照災害通報的規定，我們在二級跟一級開設的部分，會有不同的時間點，要求地方政府回報收容情形，必要的時候，中央災害應變中心也會即時請地方政府來作收容情形的提供資料。

應變中心會依照規定的時間，彙整縣市回報災害應變有關於避難收容的資訊，並回報整個收容的情形。定期更新地方政府安置收容的狀況之後，在災害應變中心的工作會報的時候，會向主管的部分來做報告。

整個操作的部分，我們實際上在剛剛提到的地方政府，就會有通報表填寫的部分，在系統的畫面請長官參閱。

我們「下層資料彙整」以帶入縣市政府最新回報的情況。經過執勤同仁正確性跟相關修正之後，才會針對工作會報的相關資料來處理。

其實整個EMIC跟系統整合上，衛福部會與時俱進檢討避難收容處所的整備相關規定，我們也在建立可收容容量的計算方式跟參考，作為地方政府收容量的參據資料。

這個部分目前為止已經委託相關的專家學者來作研究，預計明年初會有相關研究的報告出來之後，我們再跟地方政府交換意見，然後作為未來收容量能參考的依據。

另外，再針對EMIC系統操作介面的便捷使用，如果是避難收容處所，其實之前都有作相關的清查跟公告，如何在系統裡面透過下拉式的選單方式整個登打時間跟輸入資料正確性的部分，可以做精進。

另外一個部分，目前也碰到收容跟累積收容人數上會有一些規則上的部分，地方政府在手動填列的過程中會出現一些不合理的情形，在實際上填列的部分有一些不同。

如何增加一些防呆的機制，我們會持續精進，以上是衛福部的報告。

非常感謝衛福部。

剛剛提到了一些我們說地方政府的痛點，我們在6月27日去首長災害防救座談會，其實很多地方政府的代表有提出，其實EMIC之前有一個規劃案，可以比較自動式來規劃這一個問題，所以是不是就開始報告。

主席、各位與會先進，我想接下來消防署來報告避難收容現況跟未來的規劃。

大綱包含現況說明、未來規劃及有針對自動統計人數的概念來提出報告，詳細的說明如下：

首先，平時整備的作業，我們看到這個系統裡面，可以把衛福部避難收容處所，目前已經可以成功地介接進來，同時也保留EXCEL檔案匯入，平時把這一些避難收容處所來彙整。

另外，在查詢的時候，我們在點選，系統會預設到相關的避難收容處所，因為這可能有一點不太正常地顯示，這個是一個表格，表格點選以後會自動跳到地圖上的地點。

另外，避難收容處所裡面的物資，也可以把衛福部的系統當中所建置的這一些物資帶入，就可以看到這一個處所裡面相關的物資。

在實施避難疏散居民的部分，也可以把所有住民的資料，又或者是像避難的弱勢、老人、行動不便者或者是慢性病的患者，可以預設用EXCEL的檔案會如，然後災時的時候要把這一些人避難疏散撤離出來的時候，就可以做，單筆也可以這樣作業，也就是一筆筆登打。

居民資料查詢，同樣這一個表列的居民，也可以同步在地圖上顯示點位。

我們接著看疏散撤離的流程，首先業務的系統上必須要先設定撤離區域，然後會產生撤離的名冊，依照這一個名冊來去執行撤離，最後撤離情形的回報，關閉、結束撤離的作業。

首先要先設定撤離的區域，我們有兩種方式：

第一種方式是行政區域的方式，去設定要撤離的裡面是裡面的人，這裡面可以產生撤離的名冊。

第二種方式是，土石流的溪流有點選出來，如果有發布紅色警戒，相關附近的居民跟撤離的對象都可以產生出來。

再來是名冊，可以預設這裡面有多少的人員在內，依照這一個撤離的名冊，交由公所或者是村里長去執行疏散跟撤離。

而撤離的名冊同樣在土石流檢視區域也可以這樣來產生，撤離之後列印出來，交給村里長，交給名冊來進行撤離。

執行撤離之後可以依照實際的進度跟情形，這邊表列幾個項目，像「自行離去」、「不在場所」，如果手持的電腦設備有的話，就可以上網登打，不然就要回到辦公的地方，有網路的地方再輸入。

如果有設定到去哪一個收容處所，我們在這邊登記起來、把它寫起來去哪一個收容處所，我們收容的作業就可以自動帶出來這一個人的人名及資料。

如果有新增，像旅客或者是新回來的人，像臨時的住戶，也可以增加單筆增加的方式去新增撤離的人員。

有關於收容安置的作業，我們首先開設避難收容處所，平時要先新增收容處所，災時的時候開設，開設之後就接受收容人員的登記、離開，然後產出收容名冊回報，最後結束是撤除這一個收容處所，就完成了收容的作業。

首先要把預設已經有資料的處所，先開設起來，這在系統當中也是預設了行政區域當中，我們點選相關的資料，開設了以後，其他的EMIC上，對民眾的這一些資訊，就可以看到這一個收容處所是開或者是關，裡面的人的聯絡電話或者是地址，在這一個動作都可以完成。

民眾進去之後必須要登記，在撤離時，有一些預設的收容處所，就會帶出人名，臨時新增也會透過單筆的新增把它建立出來。

我們以這幾年的統計來看，我們以104年至106年執行的狀況來看，通報表是實際發生的案件、人數，前面兩個欄位，系統欄位是操作系統，用系統來執行填報或者是執行疏散的避難收容，這兩個大項其實有相當的落差。

表示真正在用剛剛講到的步驟、撤離及收容的人數，遠遠少於實際發生的人數，就是很多的避難收容人數、收容安置的人數，是沒有經過系統的操作而直接去的，這個是目前的現況。

我們今天討論106年的收容人數，我們把收容的人數匡起來，就以第三個的「泥沙季收容人數」，實際上是938人，但上面寫3,272人，所以人數是有相當大的落差。

後面的檢討有一些未來要策進的方向：

第一，各個收容處所不一定有電腦、網路，所以系統應該是手機、平板都應該可以使用，或者是可以離線使用，有網路的時候一樣可以作業，有網路的地方，再把這一些數據傳出來。

第二，在登打的時候，應該要更方便，所以這一些資料的輸入，應該是用點選或者是下拉的方式，讓人員很容易操作。

因為我們希望減少地方人員在操作的步驟，希望把重複登打的問題解決，這一些數字就直接帶到通報表，但這樣的前提是必須要每一筆都確實經過系統避難疏散跟收容的作業，這樣子的通報表才會正確。

我們也會希望衛福部要求地方政府，因為實際上在執行的時候，是地方社政單位的人員在做這一些事，所以這一些工作項目，業務上這一些必須要做的事，透過業務的體系，必須要去落實、推動。

另外，就資料品質的部分，我們看到有一些有填通報表、有一些是填通報系統，像疏散清理的清冊，像一家姓王的人，就寫王1、王2及王3，這一些品質並不是很好，我們也希望透過Open API的方式或者是地方政府介接的方式可以傳上來，當然可以遮蔽部分的資料，就可以變成Open Data的資料，就可以讓民間加值應用。

另外，有關於資料品質不佳，我們也希望系統的調整，因為系統是工具，也是配合業務，而配合業務上的需求來做，所以希望系統做調整的時候，需求的訪談希望請衛福部能夠多多幫忙。

同時在地方政府的執行部分，也透過業務的起迄，請衛福部平時加強訓練，災時落實資料填寫回報。

後面有一些技術性方面，我們再由資訊室報告，謝謝。

我後續針對剛剛提到平常使用這一些業務遇到的問題及做整合的建議。

其實我們會分成兩個部分：第一個部分是EMIC的系統，其實收了許多防災性的資料，不只是避難收容的資料，所以不只會focus在EMIC介面如何改善，也就是key資料、傳資料哪一個比較方便。

現場能夠蒐集到哪一些資料，用什麼方式蒐集到正確及即時的資料，可以傳到EMIC的部分。

在未來規劃技術方面，我們希望能夠走向行動化，RWD的登錄畫面是必要的，後續克格考量跟評估，我們希望做一些離線方式的資料蒐集，比較能夠方便性達到，或者是在手機上做即時的警示，這個是App比較容易達到的。

我們在EMIC介面可以做一些下拉式選單，或者是在提供資料的時候可以有條碼輸入或者是手機輸入，晶片比如健保卡這一些的話，需要讀卡機的設備支援。

剛剛有提到重複登打，在三個小時、六個小時的地方政府都要回報資料，所以EMIC未來可以多改善輸入的方式，能夠減少人工輸入。

另外，我們要做一個匯流，剛剛有提到EMIC裡面有一個數據資料匯入平台，我們希望能夠Open資料來源。

我們會精進我們的行動化跟讀取資料的技術。

剛剛提到也許在蒐集資料的部分會有網路的狀況跟沒有網路的狀況，我們這邊提到要是我們在有網路的狀況，我們災民到了收容處所，我們可以再分為有證件、沒有證件。有證件的部分，比如身分證或者是護照，我們可以用條碼讀入，可以用行動裝置來讀取資料；如果身上有健保卡的話就要有讀卡機讀取；如果沒有證件就用手登打。

我們可以用身分證字號去核健保資料，像有維護土石流保全清冊，如果讀健保卡還有另外一個更好的優勢，有一些疾病為高危險群或者是慢性疾病可以做醫療特別的支援也是可以特別建置。

沒有網路的話，也可以分災民進來有證件或者是沒有證件，這邊可以透過條碼進來或者是手動登打，要是沒有網路的話，就是手持裝置，也就是把這一些資料儲存在手持裝置上，在有網路的時候，是可以批次傳到我們的系統上。

EMIC會針對這一些改善計畫的期程，包含行動部分跟證件讀取的部分，我們在前瞻計畫裡面會再做時程上的安排。我們明年會做基礎建設的建置，在107年、108年會做系統加強的工作。

我加強EMIC系統裡面加強輸入的部分，在現場避難收容人數的統計跟人員資料蒐集方面，我們這邊有一個簡單的介紹，也就是之前跟唐政委開會的時候，我們有一個類似路跑的管制人員概念，假設各位長官有跑過路跑跟馬拉松的話，都會分FRID或其他晶片給你，當人員跑到固定幾百公尺或者是幾K的時候，會因為FRID的晶片通過那個checkpoint，會知道你人現在到哪裡。

這一個概念導入之後，收容處所也許可以做這樣的簡單安排，這個是簡單的示意圖。

我在門口這邊加裝在幾K的地方可以偵測到人員的進出，所以當一個災民剛進來的只有，我登記完基本的資料，就配一個FRID穿戴在身上。在門口登記完資料，在人員進出的時候，剛剛提到人進來換證、登記資料，登記資料完之後就配發一個晶片給他，資料來源有可能是身分證、健保卡。

登記完資料之後，我配發FRID的晶片，通過感應區我們知道他什麼時候進來、出去，這一個收容處所目前最即時的人數狀況，我們就可以即時上傳到系統。

這一些收容的資料，好比要找這一個人，現在目前到底有沒有在這裡面或者是已經外出了，這個資料我們都可以做即時更新的的動作。

我們需要的設備有調查過，工作人員也許可以配發藍牙的智慧手環，也是FRID。其實真正去執行的話，也許是可以手提箱或者是大箱子，我們提了這一個箱子，然後送處所開設的話，就可以有建立，會有晶片、讀取器，這一些讀卡機、攝影器材及不斷電的系統。

到時候執行的話，我們可以很快把這一些裝置設置起來，就可以很快提供到收容處所的裝置，以上報告，謝謝。

給幾個建議，最近看了臺灣的廠商，有點稍微不一樣。

ID不一定要讀卡機，太複雜了，其實可以用影像辨識就好了，不管是駕照或者是什麼東西，其實打上去，很多資料都抓出來，就可以自動連結data base，不只健保卡有那三個字，所有的證件都有，只要可以辨識，這整件事都有很多，先讓雲端上去，這個是很好的處理，儘量不要人工登打。另外，儘量讓影像IDK轉成文字化。

第二個部分，我剛剛去韋喬公司，臺灣在做高階RFID，這個事情還是一個issue，有人會換戴RFID，這個是一個問題。

同樣的問題，人臉的辨識系統可以做到80％、90％左右，這兩個可以連結在一起，對你的裝置是沒有影響的，像進出口系統是推人臉辨識加RFID，準確率非常高，就是一台手機跟唐政委的電腦，還是可以辨識，就多一個軟體而已。

反正都是靠軟體，儘量用影像的技術來處理這一件事，只要手機、筆電有的話，就那一拉動，這個是實務上的建議。

謝謝，今天的主角應該是地方政府的朋友們。不過既然我作為軟體工程師被cue，我就講一下軟體工程的部分。

剛剛聽到要做App，我比較訝異，之前都沒有聽到，表示這個是這幾個月冒出來的想法。

其實如果做離線使用跟通知，不需要用App，用Web技術就好了。現在有一個PWA的技術，已經可以在Android上運行，蘋果這邊也開始實作Web App Manifest標準。

因為你做App，你要開發兩次，如果你用PWA做的話，可以直接跟你們的網站系統整合在一起，也不用找另外的兩家廠商來做，也不會被批評兩個App Store更新速度和網站不同步的情況。

以上是以軟體工程師的身分發言，現在回到主席的身分。

剛剛提到系統跟通報表不一致，剛剛提到通報表多很多，但現在沒有，你剛剛提到桃園跟南投是反過來的，反而是系統裡面有，而通報表裡面沒有，這一個意思，從我的角度看起來，這兩軌，實際上兩個方向都沒有接起來，不只是重複登打的問題而已，而是完全不同步的問題，我想這一個問題，也是我之前從地方政府朋友們聽到最多的。

不管是衛福部在使用者經驗上或者是EMIC這邊都提出來一些具體的想法，我比較想要請地方政府的朋友們指導一下，看有沒有你們覺得在這一份簡報裡面還沒有聽到，而現在真的是在登打時的具體作業上有困難或者是收容處所上花你們太多時間的部分。

我們用簽到單的順序，台北市政府、新北市政府，依序寫下來。

1. 其實台北市有自己開發的防救災作業支援系統，並不是直接使用EMIC系統來做災情通報等工作，所以對於EMIC這一個系統，尤其是疏散收容子系統並不是很熟悉。2. 有關收容部分，提供本市近年來的小進展給大家參考，我們曾考量若遇到大規模的震災，需短時間完成大規模收容，所以結合g0v民間資訊社群，合作開發災民證APP。希望在收容登記的當下，避免讓災民填寫過多繁複表格，同時利用APP掃描條碼的方式，後續災民在收容所要領取物資或接受其他相關服務時，都可以用所得到的那個條碼來進行後續的管理與紀錄，節省很多的人工登打時間，同時在這幾年也不斷地透過演習的機會測試，並且持續改版與調整收容流程。

3. 剛剛長官提到收容安置要使用RFID與人臉辨識的部分，我覺得聽起來非常厲害，但我覺得在地方政府實務上來講，是滿難辦到的狀況，因為各縣市政府的收容安置處所非常多，剛剛所提到的收容所需設備，需要所有的收容安置處所都配置一套，在經費上與實際運用上可能有很大的困境。

簡單來講，收容所的同仁一定有手機，但手機之外的東西不一定會有。

剛剛有提到災民證，我理解這個是g0v社群貢獻者開發出來的，跟大安區公所的一個合作，然後你們最近還繼續有修。

一定先疏散，但我看到現在的，其實系統上設計的一個理念，是先有這一些戶政的名單，或者是先建的這一些名單建置在名單當中。

但是就我的瞭解，至少六都的民政系統，因為個資的關係，都沒有辦法導入，以至於在現在EMS系統上沒有這個功能，所以EMIC沒有辦法操作。

剛才其實很多的假設條件都是民眾願意配合的情況之下，以現在的操作之下，民眾提供個資會有疑慮的，技術上或許是可以做，比如可以取得民眾的身分證、健保卡及相關的資料，但實際上我們是否需要在收容的第一個時間來取得這一些資料或者是其實我不知道EMIC系統為什麼要在第一個時間讓中央瞭解收容民眾的詳細資訊，我相信在很多個案的處理上都回到地方政府，也都是後端的事情，在第一個時間上我們可能也沒有辦法在第一時間讓所有的同仁操作這一些系統或者是設備上的工作。

另外，其實我們現在在提平板或者是App的操作，其實新北市這兩年也有跟社會企業合作，也有嘗試研發App，我們定位在大型收容系統或者是原本的收容系統不足來做補位，新北市來說的城鄉差距也是有的，在一般的偏鄉狀況之下，不論是設備上或者是公所同仁使用的困難或者是接受度在平板跟APP的設備成本上，這一、兩年來，反應在操作是滿困難的，因此如果有後續規劃的話，看是不是要一併考慮。

另外，是不是在第一時間上去操作這麼詳細的資料，就像剛剛所談到的人臉辨識或者是RWD的這一些技術，其實如果在後續中央可以幫我們設計這樣的功能，我們都是樂觀其成的。

像今年各縣市的政府都是直轄市為主的，像縣轄市，比如屏東的林邊等等，是不是可以落實到操作，我有一點疑慮，以上分享。

非常感謝。

對於我們在地公所小型開設的時候，有關於系統的建置很快速，抄一抄就好了，如果要登打，科技可以解決很多快速，但在偏區跟山區很有可能中斷網路，而且公所的人力有限，可以讓科技解決，不要讓他們花費很多時間，因為災民一進來要吃、喝，要領物資，還要登打跟上傳，我相信中央部會都會考慮。

針對大型的部分，我們過去在81氣爆，跨區域的案子，人數多，趨勢需要這一套系統，我都來不及抄，並不是3、5個，而是好幾百個，確實透過影像辨識是可以很快速理解。

其實還有一個是工作湧入，有很多志工，願意進來幫我們發物資、發便當跟煮食，但工作管理的安全性，像一堆人湧入安全性，很多人擔心，但來不及作識別證或什麼，但我們還是樂觀其成。

如果今天人臉辨識進來，有無領物資、性別要分配宿舍，如果有科技協助在第一線的運作，我相信這一塊很有幫助。

包括台北市、新北市所講的部分，確實在六都裡面，區公所是直轄於市府，但很多是民選的地方政府，所以很多困難點是需要聽在地的聲音，以上發言。

謝謝。請新店區公所跟甲仙區公所。

有關於收容所的管理建置，我們也是 樂見其成，新店來講，因為比較靠近扇區，所以每一次颱風來的時候，最多有開放到六個收容所，在本所的部分，像以我們來講的話，是沒有辦法負擔的，我們公所的部分，大概只會負擔兩個活動中心，其他三至四個是由學校的人員來協助的。

未來建置的部分，不是只針對公所的部分，可能也要跟教育局的人員通報，還有警衛跟志工人員來訓練，以學習這一套機制。

另外，基層比較有疑慮的部分是，如果對於人員的管制部分，像收容所最多有收容到一百多個，也就是溪州部落，有一百多個，人員進出非常頻繁，這個是屬於開放式的，我們的人員並不是那麼大的，我們要提供很大的空間，但居民認為要到很遠的地方，希望就地管理，因此真正能夠收容的是有限的，大部分是在外面聊天，因此真的要做管理，真的是有困難的。

我們也怕會不會管理增加，而增加公務人員的負擔，如果人員離開這一個地方，然後去到別的地方，並不是回到原來有可能自在的地方，衛福部或者是其他的長官是不是要求我們知道住民到哪裡，我想我們沒有人力來追蹤。

是不是可以設定沒有在自宅的地方就可以了，不要再追蹤，不然會增加我們公務同仁的負擔。

瞭解，我們知道如果真的增加你們的負擔，最後不會去用，這個是現況。

剛剛各位長官所講的，其實也就是我們甲仙面臨的問題，甲仙歷經莫拉克過後，我們在應變能力已有提升；其實大部分的地方，以區級的應變中心來講，我們都是以預期性的風災為主，我想各區公所或者是各縣市政府的鄉鎮應變中心應的如此。

能夠遇到像0206美濃地震，其實是一個小規模的地震事實，並不是大規模像921同，我們當然儘量以預期性可以判定災害的類型去作處理，以甲仙來講，我們是屬於偏遠市區，我們不能講鄉，因為現在是直轄市。

這樣的收容處所是一個活動中心的話，其實是有單一固定門口較可控制的，但像很多收容處所會倚賴所謂的廟宇，而廟宇的出入口就不一樣，如採感應條，設置上似有困難。

另外應變中心工作人員要輪職二十四小時，我曾經輪過好幾天，同仁輪班人力極度有限，收容處所就須要仰賴廟宇的工作人員。

對於偏遠市區或者是鄉區，其實在電腦資訊化的操作，其能力是極度有限的。

我們發現今天立意良善的設備、設施，其實對於時效性是會有掌握的，但我們覺得在操作上，還是有其顧慮點；其實我們以甲仙為例，實際居住人口約兩千多人，會操作手機的人，多是在那邊工作的外地人及較年輕的民眾，老人家多不會用，我們撤離的人卻多是這一些不會用的人家。

面積幅員大小的問題、交通狀況皆對撤離有影響。

其實區公所的災變應變中心能力是有限的，像我過去在三民區公所，完全不一樣，人力也不一樣，但是現在在山區，卻不一樣，所以差距性是滿大的。

當然我之前來看過簡報，如果這一次的改善儘量是以我們在操作上能夠減少人力及時間成本是可以操作的，因為撤離時間都已經不夠了，我們多以有限時間在後端慢慢再補充這樣的能量，但也擔心上級立即性要撤離人數多少、收容人數多少，而我們已處在撤離狀況中。

除預期性撤離外，還要面臨突發即時性的撤離，如有一些人再跑回去，因此我們還要再撤離。

像去年的梅姬颱風風雨都來了，我們跟六龜在風雨當中撤離，而那又不太一樣，這個是我個人的意見。

謝謝。

地形圖其實不一定這麼理想，這個是一件事。

另外，實際在收容或者是撤離的過程中，其實有時速度或者是量是非常快的，也不能假設民眾都有手機或者是民眾的手機都可以被追蹤等等。

事後登打也是重要的，因為在當時真的完全沒有時間，不要說從10秒鐘變成1秒鐘，而是連1秒鐘的情況都沒有的，大概是這樣。

我不知道剛才沒有發言的其他朋友，像吳老師辦公室的朋友，有沒有一些想法？

沒有。

我們想要設計這一個，是想解決反應給我們的問題，也就是3小時、6小時要填一次通報表，我們有發現通報表跟系統登錄都不一樣，我們的目的是這樣子，所以我們才會做一套系統。

當然，災民湧入的話，不可能登打，一定先讓他進去，要他帶身分證、健保卡，扣除身分證、健保卡，實際上要登打的人並不多，系統的設計架構是這樣子來的。

當然你要講說有幾千、幾百人，或者是收容的場所是開放的，這個要另外設計，因此我們在提的時候是有一點示範性質，因為我們發現收容中心人數上下都是50人左右，我們也逐一問過八個鄉鎮市區他們只有二十幾個人，我們手抄一抄一下。

我們找廠商來demo，也就是你們出口的行李箱，也就是接電腦插一插，這樣就可以用了。

這個是可預期的災害，如果真的一個地震來，這一套系統，我們跟各位說這個是不適用的；如果可預期颱風來，花2、30分鐘布置，一個人就可以做起來。

人臉辨識我們也找過相關的廠商，要有資料，不要有白名單，也就是這一些人要拍照、建檔，抓到你的臉部就可以讀出你的資料，這就是一個很大的工程，所以這一次為何沒有提到臉譜捌辨識？

我們為何要做RFID？其實我們是為了配合晶片身分證，像在台北都有悠遊卡，高雄都有一卡通的功能，都有那個功能，如果用習慣的話，就是像身分證，這個是我們的設計架構。

當然也有不完善的地方，我們希望從撤離到收容這整個可以掌握，當然撤離有撤離的名單，還有會到收容中心的名單，希望能夠上網，也就是整個設計流程比較大，因為發現人數沒有辦法掌握，3至6小時的人數很累，這一個key in人數不真實，只是抓一個大概數，因此我們會發現系統跟通報表不一樣。

如果這一個案子有成，就後續再慢慢來改進，以上補充報告，謝謝。

謝謝。

我想剛才大家不管是需求或者是一些擔心的點，及技術上的說明，大概都有。

不過這個的需用機關還是以衛福部社會司提出來的一些比較快速的，也就是「未來策進作為」，的下拉式選單跟登打的部分，我覺得這個是最需要的，從最需要的先做，再說我的祖父、母在哪一個收容處所等等。我們現在面臨一個狀況，有手機、FB、Google就直接用那兩個網站的報平安功能就收到了，或者是家裡的LINE群組就說沒事了，如果沒有用手機習慣區域的話，就像剛剛有兩位都有提到，第一時間去的時候，配合或者是有那個習慣去拿感應式的未來晶片卡或者是身分證出來給你掃的流程、動線，包含工作人員的培訓這都是比較困難的區域，也就是會變成專門解決了問題，好像問題已經在差不多解決的區域，未來會很有用，但是在比較困難的區域，先天上有一些需要克服的點，因此這一個部分，我覺得是不是相對先做哪一些的重要性，先請衛福部社會司快速跟我們講一下最重要的方向是哪一些，我們開始做的期程是怎麼樣。

相關錯誤訊息的部分，可給地方政府跟公所來處理，這一個優先的部分，可能要麻煩消防署這邊提供我們協助。

有關於地方政府跟公所有提到一個情形，就整個資料管理上，地方政府跟公所在災害發生時，有關於收容安置這一個部分，我們訂的首要任務是先滿足災民基本生活需求，後續的部分再來作資料建置的部分。

如果後續有一些在資料建置的部分，還需要跟本部、地方政府有一些方向上或者是要求上的協助，這個部分我們還會再跟地方政府說明。

我想系統上的部分，我想地方政府跟公所的首要任務應該是保障災民在第一時間的安全跟基本需求，相關的資料如果登打上有一些訊息或者是數字上的一些誤差，我想還是可以做其他的精進，以上報告。

我可以問一個問題嗎？EMIC現在提到的，通報表跟系統脫鉤的情況，我不曉得你們有沒有什麼想法？

也就是用什麼樣的方式來解決這一個問題，這個是最簡單的？我們先不想新的系統。

我們補充一下，一方面疏散收容系統其實是沒有經過縣市的審核，是由公所直接登打，但通報表是公所上傳到縣市，然後審核之後會送到中央，我們相信數字報上來的，是經過審核的。

剛剛有先進提到如果透過一些機制，他們可以掌握收容所內的進出，就不用3個小時或者是6個小時通報的這一件事，我們比較擔心，一方面是災害應變這一件事應該是分權負責，我們也不太能夠去確保公所直接登打的資料，也就是是不是可以在中央應變災害中心陳報的資料，這個是一個部分。

另外，剛剛有提到的一些建議，其實通常都是針對通報表在登打的建議，比如像下拉式選單，如果現在公所的人員的新店區開設收容處所，必須登打名字之後，然後再選開設的時間，登打目前收容人數跟累積的收容人數，是必須要逐筆登打的。

如果縣市是他們自己要增加的時候，可以幫公所去修，但等到下一報，要再更新資料的時候，他帶到的有可能還是公所的錯資料，這個是很耗費我們在災時應變的人力，尤其是災時大家都很忙亂的時候，所以我們每一次跟縣市要資料的時候，縣市都會覺得 我們對他們是一種干擾，我們也有一點無奈，但基本上現實的狀況就是這樣子。

有一些防災的機制，我們之前也有反應過，好比像累積收容人數絕對不可能低於目前的收容人數，又或者是累積收容人數這一報的資料一定不會少於上一報的資料，所以如果系統上可以透過一個防呆機制讓錯誤的數字無法登打的話，我們後端就不用一直確認這一個數字跟上一次的數字是不是有問題，這個是很花費我們的時間。

另外，我們之前也有提過，比如縣市沒有開設收容所的狀態下，他們是不是可以直接點選無資料填報，因為當縣市尚未有收容的時候，我們需要確認他們是沒有開收容所，而不是忘了去填，因此我們之前有針對無資料填報的功能，是不是縣市點一個按鈕，就可以告訴我們有填了，但實際無收容的情形，而不用像現行的機制，縣市沒有開設收容所的狀態下，還需要填報一筆告訴我「無」，然後我才知道這個縣市有填報而無收容，諸如此類的問題，以上說明。

其實我在提這一個問題之前，我一直有一個疑惑點，我們這一個系統的目標是鎖定在什麼樣的類型？

目前高雄市政府遇到的大部分狀況是小型的災害，因為雨量警戒達到，所以到我們的收容所渡過一個晚上，然後就離開了，我們必須要花很長的時間去建置資料嗎？為了一個小時、一個晚上的時間，把這一些民眾的資料、名字上網公告，有需要嗎？這個是我疑惑的點。

第二，高雄市遇到很多大型的災害，其實會是一個撤鄉的狀況，像我們在莫拉克把整個原住民鄉整個撤離到都會區，其實那樣的狀況之下，原本的區公所，那個時間點是沒有能量的，其實是整個已經移到縣市政府，甚至是卡區的縣市公所負責整個災害任務，這時在地需求跟遇到大型災害的需求又不太一樣，因為那個時間點不是原本在地里長、村里幹事可以遇到的狀況，民眾全部都撤離到另外一個鄉去了，所以要考量小型災害跟大型災害很明確的差別。

小型災害會有價值功能比的問題，我花了很多時間在建置前端的資料，但我可能實際的用途，也許是一個晚上，而一個晚上之後，隔天民眾看到雨沒下，就全部回去了，因此有無必要在這一個時間點做這一件事。

另外，我要針對剛剛消防署有提到通報表的人數跟撤離人數不一致的問題，其實有一個核心概念，也就是沒有跟戶政系統連結，所以今天比如甲仙區在撤離系統當中，必須要把所有的保全人口建入這一個系統，而甲仙區的實際居住人口是兩千多人，戶籍人口六千多人，戶籍都是在土石流建置區，所以如果要建置這一個撤離系統，必須要把六千多人的個自一筆筆建置起來，但卻沒有跟戶政連結，所以我在3月的時候匯了一筆資料，到6月的時候，這一個民眾就離開了，或者這個民眾是其他區的民眾，到災害的時候住進這裡面，我根本沒有辦法更新這一個資訊，因此基層的人員為了要更新保全名冊、系統名冊，花了非常多的時間，但在災害的時候，我們只需要回報甲仙區收容多少人，男生多少人、女生多少人，這就是做白工的工作。

另外，我花了非常多的時間，建了一千、兩千多名民眾的資料，但實際在災害的用途，完全用不到，因為來的時候，里長都很清楚知道你叫王小明、大明，根本沒有時間也沒有必要去拉這個名單，這個是我對消防署的回饋，以上報告。

消防署之前有回報戶役政系統的事？

但是非常困難，我們有試過，但很困難，最後沒有成功。

所以不是法規命令，這個完全符合個資法的要件，所以不是法律上的問題。你剛剛講的是技術問題？

可以，但是很難。

我們如果花一點力氣，可以換得第一線人員不曉得多少的時間，所以處理一下還是滿有效的。

其實這個沒有很高的經濟效益，而且戶役政系統不代表當地居住的人，有縣市政府的人跟我們反應，登打可以抓進來，但不代表全比的居住人口，所以回歸到規定的保全清冊，固定要彙整這一些名單是不是正確，所以比戶役政系統更有用。

這個針對疏散撤離、收容的這一件事，中央、地方做到什麼樣的程度，這個必須要有整套業務上的規劃，我們希望由衛福部來處理。

消防署要做EMIC系統，必須要做這一些東西，但我們還是要講系統只是工具，而是配合業務的需求去產生，如何讓這一個業務能夠更快、更方便達到，但至於這一個業務要如何用、中央要不要這一些資料？如果衛福部不要，我們也不需要。

大概理解，我想立場很清楚（笑）。

我們想省地方登打的力氣，本身是有意義的，不是沒有意義。

這並不是中央跟地方分層負責的問題而已，而是一個資訊系統，如果好不容易建置了，但是用不到，或者三個月或六個月之後不對了，寧可有一些保全清冊或者是輔助的東西。不然沒有省到力氣，大家就會不來用，剛剛台北市政府已經說了。但如果有省到一些力氣跟輔助的話，就會來做。

聽下來，有沒有別的腦裡冒出來想講的？又或者是可以做，但還沒有做，未來可以繼續做的？任何人都可以發言。

如果都沒有的話，我想我們的順序是這樣子：

以EMIC系統，目前實際所提供的，也就是衛福部社工司作為主要判斷的依據，剛剛有提到優先要修正的，還有在畫面登打比較困難的，還有有離線需求，這一個事實上是有的，我想以這一些部分優先。在我們做提一個行李箱或者是設定任何新硬體之前，我們先把這一些最基礎的東西列進期程裡面。

第二個是，第一線的很多朋友有提到，我們做「有手機、平板就可以使用」的系統之前，我們還是要進一步做一些使用者的訪查，而這一些訪查的工作，我想消防署一直是說由衛福部這邊來主導，然後消防署這邊的廠商去配合。我想請這兩個單位持續溝通，然後去安排在任何實際需求做出來之前，任何的構想，可能用草圖、假資料或者是靜態畫面等等，以使用者導向的設計方式，實際去各個地方進行一些工作坊。

其實我們在報稅軟體的精進案有執行這樣的程序，也剛完成明年跨平台的設計。如果對使用者體驗的流程，我們辦公室很樂意提供協助，也可以去詢問其他有做過類似體驗工作坊，以我的理解，台北市政府之前就跟社群做過，以演習的方式對這一個介面進行改善，所以也可以先實際詢問進行的方式跟步驟，我想就會比我們自己埋著頭做要好很多。

另外，剛才葉副執秘提到，系統真的進行到條碼要掃的程度的話，儘量不要用額外的設備，儘量以一個手機鏡頭為主。健保卡上的身分證字號，掃進來並不困難。

手機上的離線應用，請使用PWA，而不要用App開發，這個是技術上的提醒。

期程還是請單位繼續協調，這樣可以嗎？

有沒有其他的動議？如果沒有的話，我們就5點結束，謝謝大家。