另外一種新的發想是,我在現場拍一張照,然後傳到內政部去,內政部把這一張照片跟裡面的電子檔比對,如果類似的話,就會跟你說這個人是本人。
再來,你可能可以用自然人憑證換MyData,那裡面可能也會有你的照片。
第一,我們可以連線到內政部的身分證系統,因為內政部系統裡面已經有所謂照片的電子檔了,但要如何授權人家可以去內政部裡面調閱你的電子檔呢?你可能又要拿你的身分證出來,其實你已經有拿身分證出來了,因此這部分可能還要再討論一下。
身分辨識有提到如果虛擬卡有照片跟沒有照片有不同的做法,如果虛擬卡沒有照片的話,現在的做法是比如沒有照片的話,必須要搭配身分證或是搭配戶口名簿(如果你是小孩的話)。但是如果你是虛擬卡有照片的情況之下,這個照片又要如何去取得驗證?這邊有提供幾個發想,但沒有做非常詳細地研究:
接著,報到的時候需要做身分辨識的這一件事,我們卡了一陣子,因為身分辨識其實在就診、批價及領藥的部分都會講到,剛剛也有醫生提到就算在這邊做身分辨識,其實每一步都還要重新做一次,因為這個是機制上的問題。
接著是掛號報到的部分,在實體卡上大家非常強烈建議要有雙介面,因為這樣才可以有舊的相容,我們剛好也有相關廠商的同仁提到雙介面卡基本上跟單介面是差不多了,這個是下一個部分,不過剛好有提到,所以我就先講。
比如有一點像以前實務上沒有帶卡的時候,可以用押金的方式,但是在這種情況之下,醫生就不能開慢性病的藥,類似這一種限制它必須要有這樣的狀況可以處理。
再來,當你授權虛擬卡的時候,醫生可以做的診斷範圍也要有所規範,因為你是拿主卡的話,那可能就是最大的權限,如果是拿授權出去只能看一次虛擬卡的話,在安全性的考量上,我們希望連醫生可以做的診斷都是可以有規範的。
授權的部分我們也有討論到,如果在授權的過程中,其實應該把我可以授權多少的資料到虛擬卡上及虛擬的副卡上,這部分應該要有一個規範,但這個規範我們就沒有詳細討論,基本上是講敏感資料及不敏感的資料。
在這種設計的情況下,我們就討論到另外一個問題,如果今天有一個緊急情況,但是只有主卡,然後主卡又被鎖,怎麼辦?這時我們說可以搭配醫事的HCA,醫事的HCA可以強制解開主卡的部分。
有了這樣的設計之後,後面的授權就會變成當你的主虛擬卡授權給某一張副虛擬卡的時候,主虛擬卡會暫時鎖住這一張虛擬卡可以用的權限,目的是因為有多張虛擬卡同時存在的時候,除了風險提高之外,資料同步也會是個問題,因此他們希望有一個主暫時停止使用,然後副卡使用,副卡使用完之後再去解鎖主虛擬卡的這種設計。
虛擬卡的部分,這有一點牽涉到後面授權的部分,在虛擬卡上面,他們希望設計可以有一個主要虛擬卡跟副虛擬卡的部分。
在虛擬卡的部分,其中一種做法是實體卡換虛擬卡,我們藉由讀取實體卡的資訊來證明你擁有拿虛擬卡的功能。
從一開始的領卡跟大家講,其實我們有考慮到實體卡跟虛擬卡的部分,他們在討論的過程中,大家把實體卡分為新發、補發,可以拿舊卡換新卡的這種機制,以及你實際上新領卡的這種機制,雖然現在新領卡的機制可以不用到院所,但也有同仁希望還是必須臨櫃申請,如果是舊卡換新卡的話,他們才覺得可以做到不用臨櫃申請。
我先解釋一下為什麼是我說明,因為剛剛討論的過程中,大家非常踴躍發言,所以我們有一點發散,應該只有在我腦海裡才可以整理出一個可以說明的路徑。
是,除了計算震波到達的時間之外,還可以計算這個區域的震度有沒有到達應該要彈出字卡的標準。
是機上盒上面計算。其實這一個部分都有討論到,是要頭端計算或者是機上盒計算,如果頭端計算的話,一口氣要計算全臺灣收視戶的位置,這樣對他來講比較慢,不如把接到的訊息直接發送到機上盒上面去,讓機上盒自己算所在的位置,這樣可能反而會比較快。
並不是機上盒自己抓中央氣象局,而是中央氣象局的應用程式裝在各平台的頭端,平台的頭端forward這個訊息到各機上盒上面去,然後把最需要花時間運算的部分放在各機上盒去算機上盒的位置、自己的震央離他多遠,它還是要透過頭端送到各機上盒上面去的。
更正一下,是氣象局,這個credit要給對。
林雨蒼一邊在大家報告的時候,他就一邊做兩組的統整,因為兩組有比較相似的想法,我們可以看一下他統整的結果。
技術的部分我先補充到這裡。
我們就想說這樣的模式是不是可以複製到機上盒,所以只要把應用程式裝在各平台的頭端,接上去之後就把訊息灑出去,然後可以計算距離震央多遠、要不要彈出字卡,第一次可以節省中央氣象局到平台的傳輸時間,因為計算的東西都不在平台上,所以平台也不會慢,平台又可以很快發到機上盒去,因為是自己算自己的,應該會比較快,算完之後就可以比較快彈出來。所以我們在這上面跟一開始原來指定頻道跟轉台的做法,我們少了指定頻道的節點跟轉臺的訊號,我們只是發訊號過去彈字卡,花的時間跟複雜度都是降低的。
我們再繼續討探討的時候,發現原來應用程式只給震央的資訊,就是這個震央在哪裡、震度多少,所以送的資訊很少、可以送得很快。在各個電腦上的應用程式就會開始計算震央離這裡有多遠,S波推估是多少,因此計算這一台電腦的這個地方要不要發地震速報,其實地區性的計算時間是花在那一台客戶端的電腦上。
你不可能會拉專線到國中、小,我們發現是走網際網路,這樣很好啊!我們就copy這個模式到平台業者,就可以在平台業者,不用透過MSP,直接很快速地把訊息送到平台業者。
比如說一開始的時候有討論到拉專線,大家都知道拉專線很貴,所以我們就快速放棄它,但是我們又聽說國中、小裡面都有裝程式、會接收預警,我就開始好奇了,這個國中、小到底幾秒會接收到預警,結果一講出來驚為天人,只要0.2秒,我們嚇了一跳,為什麼它會這麼快?
因為我剛好是這一組的,所以我就上面技術面的部分補充一下剛剛討論的脈絡。
我們先請這一組的代表。
因為這個分享的時間可能會15至20分鐘,所以大家如果覺得腳酸可以找個地方靠一下或者是坐一下,沒有關係。
兩組討論完、時間也差不多了,我們請兩組分享一下,剛剛討論的結果。
因為等一下我們會把桌子合併,私人的東西要收進包包裡面,稍微移動到比較旁邊的位置,我們會有工作人員協助作分組,謝謝。
等一下收東西的時候,可以想一下誰跟誰要一組,要到這邊或者是到另外一邊。
我補充一下,因為我們分組的時候,會希望兩組都有不同單位的角色、立場,所以像提案人、附議人,我們會希望你們在不同組,NCC的幾位同伴,我們會希望你們拆成一半,不要到時候一組有內政部消防署的人,另外一組都沒有,這樣討論起來很奇怪。
在這之前,我想先確認一下,有沒有人想到有什麼問題,如果要在電視上發布地震速報的話,我們應該要考慮到哪一些面向?有什麼想法可以先提出來幫我們補充一下?謝謝。
下午的時候,我們可能會針對類似這樣的問題去做一些可能是概念或者是可行性的發想,今天剛好很多不同的專家都在場,有災防、電視、資訊系統的專家都在場,我們就可以針對這一方面來作一些發想。
另外,剛剛有提到電視速報的環節太多、速度難以提升的這幾個面向。
另外剛剛也有一位先進有提到在電視速報上,其實有人會盯著它看,它不會跑,這個如何在電視地震速報上設計?
除了一開始有盤點到系統面該如何建置的問題要討論之外,早上又有提到其實有一些地方很重要,像如果發生誤報的時候該如何處理,這個部分也要在整個系統規劃的時候都有設想到。
不好意思,我稍微統整一下我這邊蒐集到的一些想法。
大家可能會發現自己桌上有寫著名字的便利貼,如果方便的話,其實這麼多人大家講過之後就忘了,如果方便的話,是不是可以把便利貼貼在自己的胸前,大家交談的時候,就會知道你是誰。
大家好,我是今天的助理主持人,我是Mark,等一下如果分組討論的話,我會負責一組的討論,等一下我就會把麥克風傳下去讓大家自我介紹。
你不能實際開一場之後,說「這個是模擬。」
如果大家定位這一場是議題的練習,這個要講清楚,不要找外面的人來,或者是找自己熟悉的專家學者來,我們把流程run過一遍,如果有一個不錯的產出,就用,如果沒有的話,至少外面的人就不能進來,所以這一件事媒體也不會知道,就沒事。
日期還是到8月31日,所以無論如何時間都還足夠。
我覺得那個是防禦性的問題,沒有人提到我們就不提,但是有人提了,我們也有準備要回應的答案,但是不會主動揭露。
有一個解法,是把猴子列為保育類動物(笑)。
對。
部分會有關係,但是也有一部分沒有關係。
另外一個想法是,我們也可以不要把它當成既成事實,為什麼猴子要不要降等跟討論猴害可能部分會有關係。
是開始公告嗎?
不管是問題背後的問題或者是一個政策下去所沒有解決掉的部分盤點出來,然後在協作會議上討論。