麻煩偉翔了。

政委、各位長官及同仁，今天向各位介紹虛擬健保卡委託辦理案的執行情況，這個案子是社團法人臺灣醫學資訊學會，這個案子其實議價開始執行是8月30日，我們預計在12月31日的時候，這個計畫就會結束。

其實內容第一個其實分析使用者的經驗跟障礙者的評估，我們會有如何分析跟如何蒐集的說明，還有資訊安全、成本分析，未來要推動的話，我們怎麼樣做一個可行的model與政策建議。

預算之後就295萬，得標廠商我先簡單介紹，這個是社團法人臺灣醫學資訊學會，機構負責人是張博文，這個計畫的主持人是劉德明，劉德明教授目前是在高醫大，做醫務管理暨醫療資訊學科的教授，還有一個主持人是在北醫，在107年、108年學會都有接衛福部的案子，也是以資訊的為主。

這個計畫管理有一點小，跟各位報告一下，因為這個時間有一點趕，所以時程的管理已經細到週，以週為單位在做計畫管理，裡面有幾個比較重要的時間，必須在10月30日之前要繳交期中報告，必須完成50個個案的蒐集，所以在看到「6」的時候可以看到是在10月第三週開始，也就是真正進行個案的蒐集。

在那之前當然醫院的準備、系統的準備，都會事先完成。

解析來簡單介紹一下這個案子的內容，先說明的是，我們怎麼樣蒐集民眾的資料，民眾的組成是什麼樣呢？我們會先測500位，也就是用虛擬卡就醫的情形。

這500個裡面，至少要有350個是完整、有效的個案，什麼是完整、有效個案？也就是要申辦虛擬卡到就醫、到領藥，然後到批價，這整個完成才是有效的個案。

為何500個就醫個案只有350個是有效的？因為這是試辦計畫，我們認為之所以會失敗的經驗，也是很可貴的，因此我們希望這150個，為何會失敗的經驗也要去歸納跟整理，這樣的話，才會知道試辦計畫的障礙會出現在哪裡，這個是為何會這樣設計的原因。

試辦的場域包含了醫院跟診所，醫院大概有三家，高屏區是醫學中心，台北區是區域醫院，東區是地區醫院，診所是加起來十家。

有效個案第一個是個案不可以重複，第二個是有做性別跟年齡的分組，這個案子要特別強調，要如何取得當事人的同意，經過IRB之後才可以開始辦理。

這個是整個規劃的內容，統籌規劃是臺灣醫學資訊學會，系統的部分是找全景軟體來做系統的開發。剛剛所提到的醫學中心是高雄榮民總醫院，預計做200個個案，東區就是羅東聖母醫院預計做100個，台北區是在康寧醫院做100個，診所的話，因為目前還在談，確定的是北區、中區跟南區，不包含東區，預計收100個個案。

簡單說明一下整個的流程如何，所以挑選受試者，主要是會邀請他加入，然後會幫他們下載APP到他們的手機裡，讓民眾註冊，註冊完之後會開卡，然後才會填寫問卷跟同意書，還有開卡、填寫問卷及同意書，然後批價、領藥，最後是申報上傳，這是整個完整個案的流程。

這個比較詳細一點，這個是以高榮為例，他們會挑選受試者，因為這個案子的時程關係，預計在1月裡面，不會所有的科別都去試辦，必須牽涉到硬體跟軟體，因此會預計找其中的科別，原本設計是內科，不過因為後來有跟他討論，外科現在也會放進來，所以會有內外科，然後會徵求自願的受試者，然後再審查。

虛擬卡的申請會在醫院專門設一個櫃台來服務這一些虛擬卡的民眾來做設定。

因為一開始的時候，設定最後要有一個身分的確認，也就是申請完了之後，櫃台的人還是會拿身分證來做確認，也就是確認這個是本人，這個等一下會有詳細的說明，接著會有掛號、報到、看診、批價及領藥。

健保署會給他一個特別碼，用特別的碼來做申報及上傳。

接著是示範案例，像民眾是如何註冊呢？我們會有一個APP下載到手機裡，然後民眾先拿雙證件，也就是身分證跟健保卡，這個是用民眾的手機來拍的，照片是存在民眾的手機裡，民眾拍完之後會截取資料，截取資料之後，也就是姓名、性別、出生年月日、發證的日期及身分證字號，然後要跟民眾確認是不是民眾的，如果民眾要按確認或者是修改，如果確認之後就告訴他確認成功了。

但是要特別提醒他第一次使用要開卡的時候，首先會用實體健保卡來開卡，這個是做身分的確認，也就是我們還是虛實併行，虛擬下載完畢了，接下來我們會用實體的健保卡來讀卡，確認這個人是沒有錯的，所以讀卡完畢之後，我們是用實體健保卡確認身分之後就完成開卡，第一次需要而已，後面就不需要了，這個是做身分確認的安全性。

看診之後，民眾就是拿這個QR code，這個QR code的手機當載具，下面有一個時間，這個是倒數計時，也就是QR code的有效時間是1分鐘（60秒），時間到的時候，QR code就會再換過一個。

下面還有照片，方便診間的時候，醫事人員可以確認是不是本人，QR code而掃完之後就進行看診的程序，然後再用這個手機來做領藥，然後民眾就可以完成這整個就醫的程序。

簡單說明一下這個案子的架構，這個架構牽扯到健保署，還有自己的硬體設備，也就是讀卡機，必須去做一些業務的調整，像安控元件要調整，還有虛擬健保卡的APP，這裡面有關於安全性的部分有註明要做到。

有做一個虛擬健保卡的註冊中心，這個是放在高榮，要做身分的確認及資料的儲存。

這邊說明的是，這個案子，也就是醫療機構必須配合的部分，主要是醫院，醫院的資訊部門、醫管部門、醫療部門，像櫃台及服務的部門都必須來做一些調整，像教育訓練、介接，還有一些資料上傳及加密，這個是醫院端的話，其實調整的幅度也不小，所以診所的部分，資訊系統是找展望。

這邊有特別提到，我們有特別要求廠商要說明一下他們的資安措施，他們是有提到他們的OTP採用的標準是採用目前資訊的水準，目前是希望1分鐘變一次。

他們的所有資料，他們存在伺服器的時候，他們都會加密，這個也是特別要求的，細部的內容，我們有要求下一個月要交資料的系統文件到我們的署裡面，我們會請資訊部門來確認一下是不是有資訊安全的基本規範。

風險管理的部分，像資料安全的部分，有備援機制，像安全的部分，至少有加密的機制，這個是得標的廠商有特別說明在資安的部分是有多重的系統來做確認。

預期會產出三個東西，我們可以產出的是虛擬健保卡的系統，還有註冊平台，這個是第一個。

第二，我們是透過這個計畫，我們蒐集利害關係人，像民眾以及醫療機構的使用經驗跟障礙，最後會提出一個可行性評估報告，這個案子最後主要產出內容。

有關於研究限制的部分，這有五個，在我們的討論過程中，有一些研究限制在目前的現階段是沒有辦法突破的，首先是有關於手機認證的部分，因為手機認證不管是現在的線上認證，還有最後如何做，確認這個是本人，像有拍身分證，如果是彩色影印的話，很難確認是不是本人的東西。

我們目前是用輔導員來做最後人工的身分確認，因為目前網路銀行或者是其他的行業，這個部分還是有待突破，目前的技術有一些限制。

最後第二個是，真正開卡的時候，目前也是為了身分確認的機制，我們還是有要求實體健保卡來做開卡，確認這個人是沒有問題的，這個是我們目前為了資訊安全，還是有這樣的限制。

第三個，目前的民眾還是一機一卡，因為我們的計畫雖然希望達到一機多卡或者是多機一卡，如何授權或者是授權撤銷，這個機制我們還在討論中，目前還是一機一卡，但是未來計畫結束之前，法律關係可以釐清的話，這個技術上是可以做得到的。

接下來，我們健保的部分，因為我們還有一個雲端醫療資訊系統，也就是我們要確認這個病人沒有重複用藥，這個部分目前在診間，因為健保署有要求，醫事機構要確認這個人之前的藥有沒有被重複開立，為了用藥的安全，這個部分如果要去調，全部走虛擬的話，目前調整來不及，也就是用實體來確認，不影響到申報，這個在可行性最高的狀況之下，這個是暫時先處理，這個部分我們會先在研究限制裡面。

如果從頭到尾的話，這個資訊系統也會做相應的改變及修正。剛剛有提到不管是APP的下載方式，或者是1分鐘的QR code的限制，或者是回應的秒數是3至5秒，在討論的過程中，像QR code是不是會太短，回應的時間是3至5秒是不是太久，我們也是透過這個試辦的計畫來調整，是不是可以測出比較符合醫療機構的需求跟民眾的忍耐程度所可以接受的，我們再來調整，最後再做建議，以上。

感謝。看同仁有沒有要補充說明？

我補充說明一下，基本上這一次的試辦方案，都是完全follow去年協作會議的精神，如果大家還有印象的話，其實去年的虛擬卡有兩個，一個是NFC，或者是OTP，但是在這次的標案裡面，這一家廠商是得標的廠商，提出來的案子是OTP的案子，所以是讓它用OTP的方向來做這樣的規劃，這是第一個前提。

在這樣的前提之下，事實上我們也跟學會討論過兩次，今天早上也討論過第二次。討論的過程中，基本上不外乎在談的是申請，也就是包含註冊跟開卡，這個一個動作，還有一個是就醫流程的動作，第三個是醫療院所上傳申報的動作。

這三個動作，我們在今天的討論裡面，針對是虛擬卡跟實體卡的部分，有稍微討論一下，原則上在註冊或者是就醫掛號流程的部分，我們希望有虛擬卡使用的經驗，但是在後端申報留存的部分也是虛擬卡，最後在審核端的部分，跟大家報告一下，因為健保目前針對雲端藥歷系統的部分，這個部分我們管得非常嚴格，所以有一些部分還是要用實體卡，醫療院所不會有兩筆費用或者是被核扣，這個是被處理的過程。

結論應該要這樣講，法律還沒有規定的前提之下，這個是試做的場域，不能讓他受到不利益的影響，還是要考慮到這一些變相，這個是我們考慮的重點。

第三，在區域的分布上，也就是500個人的區域分布上，我們有考慮到不但要做性別的分組，還要做年齡層的分組，這個分組必須要跟母體的結構是有一致性，所以基本上我們希望醫資會要把這四個試辦的場域來做比較好的分布，不能讓他們自己醫療院所來挑他們想要挑的個案，不能隨便取樣，基本上還是要經過設計，這樣整體出來的試辦方案結果才是我們想要瞭解的。

但是，還是在這個方案當中有研究限制，因為這一次的試辦期間只有四個月，所以，如果今天是拿慢箋病人就來一次，所以就把慢性的病人或者是復健科的病人，我們就是要再做一些立意取樣，會有一些研究上的限制，明年有機會做大規模的試做，我們會再把這個部分考慮進來。

我們今天討論到很細緻的東西，我們都有交代醫資會來思考這一些問題，如果大家還有印象的話，第二次的協作會議都是在講資安跟法律的部分，包括我們現在談的是一機一卡嗎？或是一機多卡或者是多機一卡的授權的問題或法律的問題，我們連同這一些問題拋給醫資會，讓醫資會來做下一個階段的研究。

原則上有按照協作會議的精神，然後都有跟醫資會溝通，以上。

看同仁有沒有要補充的？

資訊端還好。

資安處？

今天有跟簡處長講，也派不出人來。

那我就附身一下，我問一下資安。以我的理解，現在用這樣的方式在做，並沒有限制Android或者iOS的版本之後，他的版本好，對不對？有史以來的Android或者是iOS都可以使用，等於是測試的時候，已經放寬了資安的限制。

我看到簡報裡面有一頁，因為我們並沒有真的存到加密存放區裡，所以是整台手機複製，等於健保卡是多機一卡了，這一件事是在這個測試裡，我們特別說我們不特別測這個的意思。這個是詢問。

以我的理解，我對倒數第二段的理解，意思是並沒有用手機上面可以抵抗這一些攻擊的功能。

他們的規劃上，會覺得這個階段沒有辦法保證這一塊，建議先列入研究限制。

因為我們是在測體驗，並不是在測資安。

手機也不是有史以來的都合用，基本上還是有一個最低需求的版本。

如果是限制在最近四年的Android的手機，其實可以抵抗那些了，如果是最近五年的iPhone，也都可以抵抗了，但現在沒有把這個當作標案的一部分來寫。

但是這個限制手機一定要什麼樣的版本才可以，也會影響個案的蒐集。

我理解。如果未來測NFC的時候，因為NFC有裝的時候，差不多是用來做行動支付的時候，既然用行動支付，本來就必須要看這一些複製，不然要如何做行動支付，這個是最近四年的iPhone，也是最近的Android，以後的手機都可以用行動支付，所以如果我們未來還要測NFC，這並不是必要測，但是等於內建一個你可以抵抗這一些供給的能力，那時候我覺得我們不妨再把這個部份放到那個階段的測試標的裡面，這樣就包含了資安要5％至7％的預算打看看，可以放在那個階段做，不一定在下一個階段做，這個階段就特別說我們理解有這一些資安風險，但是在測而已。

以上，資安處附身完畢。（笑）

我提醒，並不是要馬上做，對於政府開發的APP都有要求資安要通過檢驗，我們在測試，可以說不用，但是日後如果真的要變成產品的話，要通過資安。

OTP是有一個理由，是因為知道iOS有一天會開放NFC的讀寫，但是不知道哪一天，要在今年先測某一種體驗。

現在我們已經知道iOS 13是給NFC讀寫了，這個並不是理由了，會變成一樣好用的情況。

我想資安的部分，如果大家沒有意見的話，資安就這樣做。

我們這整個簡報，這樣聽起來，因為都已經在測了，其實沒有機密的部分，等於跟逐字稿整個公開，這應該是沒有問題的。

這個都是程序性，其他是行政跟協作面，看院裡的同仁。

就醫的部分我要請教，也就是剛剛所說的第12頁。有一個開卡的程序，開卡的程序，最主要的目的是什麼？因為在前面的話，因為已經把APP裝起來了，也把註冊的時候打進去了，要在醫療院所裡面做一個開卡的程序，我這樣聽起來，感覺有一點像人別確認的一件事。

以後這樣的開卡的作業，是任何一個院所都可以做開卡的動作，人別確認之後的資料，實際上還是在雲端，也就是後面的虛擬健保卡註冊中心的那個資料庫，並不會存在開卡的院所。

理論上不會在。今天早上也是為了開卡有再討論。

我想處長的意思是，因為整個設計流程，其實註冊的部分大概問題不大，開卡的動作，其實有一點像模擬目前有一些像信用卡會有一個開卡的程序，當然這個開卡程序，有它的意義，也就是再確認，因為這個註冊流程不知道會發生什麼事，所以在開卡的流程再確認，比方前面的註冊過程可能講一個比較誇張的例子，不小心看到別人的卡，然後就幫他註冊了，開卡的設計是要插實體卡來開卡，這個在人別確認上會有更好的資安。

這個當然。第12頁的畫面是院所的人員看到的，並不是使用者看到的，看到的時候也是VPN連回你們家，所以當然院所不會存資料，這只是一個問題。

這個等於註冊的東西有開卡的註記，就可以進入就醫的流程。

我同意有一個開卡的程序，只是要到院所裡面做開卡的動作，而不是可以上一個網站，或者是自己開卡，有沒有這樣的意思。

就是需要高強度的憑證，最主要的是院所的人可以當作第一線的人員來做，我的理解是這樣，並不是反對，而是我們的思維是不是院所當作人別確認的功能。

其實技術上本身的環境是ok的，是可以自己完成開卡的動作，也就是信用卡可以完成開卡，這個是註冊這個流程是一氣呵成做完。這個是如果有一天沒有志工、輔導人員存在的情況下，這個人有一定程度的電腦操作能力，是不是可以獨立完成這一些東西，技術上是可以的，但是技術上多一些驗證。

今天早上討論的時候，並沒有像現在這麼細緻，開卡是不是要做憑證或者是密碼，這要再一次的確認，不過早上的討論是，我們去想像民眾其實是看病是拿雙證件去看病。

你要求的不能超過現在。

這個我同意。所以後來是用這樣的方式，也就是不改變民眾目前就醫習慣的前提之下，但是未來開卡的動作真的不是在後面，這個可能下一個階段要想的，這個部分就當作研究限制，也就是這一次的研究不討論到這個問題，但是或許下一個階段可以。

我們可以想像在家裡用一台電腦接一個讀卡機拿出來，然後就完成開卡了，這個是可以想像的，並不是這個階段。

第14頁裡面提到幾個跟安控有關的，像右上角有一個金鑰管理或者有簽章加解密，這個現行個人健保卡上有所謂的金鑰或者是有簽章這一件事嗎？或者是未來變成虛擬之後，就會有金鑰或者是行動APP簽章或者是解密的動作。

第二，左下角有一個安控的元件，也就是QR code掃描跟簽章有一個安控元件，上面畫的讀卡機，我的理解安控的元件跟實體卡，的確是要有安控的元件，但是因為控制、辨別實體卡是不是真偽的情形，因此有這樣的安控元件。

跟現在虛擬健保卡APP的關係是什麼？我的問題是這樣子。

報告一下，金鑰管理的部分一定會有，加解密一定會有所謂確認加解密的金鑰，目前健保卡並沒有簽驗章的問題，這個是因為當初沒有需求去設計。

如果以這個案子來看的話，金鑰功能一定會有，簽驗章的功能是可有可無，開發出來不一定用得到，但是實務上不一定會馬上用到，只是先預備一個功能，但是到時會不會有的話，可能要再討論，或者是需要時再做。

第二，安控元件的部分，概念上比較像連接這個APP跟HIS系統的動作，比較像API那樣的概念，因為如果將來這個東西要往下走下去的時候，這個階段因為我們只挑三家醫院來做，當然HIS去修改，一開始已經談好了，這個問題不大，但是如果以後要全面推廣的話，不太可能讓每一家醫院HIS大幅修改，這個推下去會較困難，所以是用API的方式來介接，大概是這樣子。

看同仁們有沒有問題？

我看起來協作會議的成果，大部分都有參採了。很感謝沒有把刷臉放進去，我們目前最不需要的就是這樣的爭議。

我們在測試的這一些人，他所有看病的資料，像用藥紀錄，一樣會回傳到原來自己的資料庫，避免影響權益。

對，一樣。

延伸一下，你們會做特別的紀錄嗎？他上傳的資料會特別記錄這一些或者是這一段時間是透過APP的方式？

我們會給他虛擬代碼，就是給這個計畫的，到時後面所有只要抓這個虛擬代碼進來，就可以知道這500個case是哪一些，上傳的資料是怎麼樣，還有用藥的情形怎麼樣，都完全可以看得到，是一模一樣的。

看大家有沒有其他想要詢問的？我是覺得非常完整，真的辛苦了。

我想最後一個，你們結案報告是設定在什麼時候？

12月31日。

包含產出報告嗎？

對。

所以只有五週可以分析出研究結果。會放到GRB？

對。

也就是可以公開閱覽。好啊！我覺得不管接下來是測NFC也好，或者是測這個精進的版本，也就是資安上比較沒有問題的版本也好，或者是真的大家都覺得非常合宜，多我們直接多找幾家醫院開始測也好，我們沒有定見，我們就是看驗收報告的實際狀況，這中間任何時候需要我們幫忙的，隨時讓我們知道，謝謝。

如果大家都沒有問題，我們就在這邊結束，謝謝。