• 部長好,這次可以再來拜訪您,真的很高興,您在政府裡面扮演非常重要的角色,郭校長說邀請這麼多人去學校演講,說您最受年輕人歡迎。最近在看很多文章,知道您非常受歡迎。

  • 大家會問說為何這件事很重要,這個產業必須是要國際化的,數位部可以扮演一些角色。我簡單來講一下,我上次完全用正面的眼光來講美國,美國在短短 10 幾年的時間就數位普及了,這裡面我上次沒有特別講的是「HITECH Act」,我只要講一張PPT,我想部長您大概就清楚美國當時的策略。

  • 這個跟 Affordable Care Act 有點綁在一起,第一個就用胡蘿蔔,其實大部分都是給 Phician’s office(診所),因為美國這些診所基本上在 15 年前都是 paper base,所以政府就拿著錢說,第一個是低收入戶保險(Medicaid),第二個是老人保險(Medicare);但是又給了棍子,每年給幾萬元(美金)的補助,說如果不這樣子做的話,Medicare payments,以後一年要少給 1%~3%。

  • 類似這的政策,20 幾年前健保開辦的時候曾經用過,但是我們那時並沒有給錢,那個時候不需要給錢,所有的人就已經數位化了,因為勞保都是紙,所以以前到勞保局,到處都是紙箱,第一任的總經理葉金川先生說:「你如果用 e-Submission,我 15 天之內就給你 9 成的暫付款。」因為他不知道要付你多少錢,但是你跟他申請 100 萬,他就會說先給你 90 萬,醫院的 cashflow 就沒有問題,以前醫院常常有這個問題,他只做這件事,就讓所有的醫院、診所在 2 年之內全面資訊化,後來當然 IC 卡是我們加碼的成果。

  • 不過我今天要特別講的是,美國用的是蘿蔔、棍子,然後讓所有的人數位化,但是少做一件事,這也是我們今天來這裡最重要的原因,也是延續上一次的討論,沒有人站出來做一個標準化的平臺。

  • 並不互通,這就是上次我最後問的問題。

  • 是的,回答您上次的問題,為何還沒有這麼通。簡單來講,最大的 Epic System 的網內互打沒有問題,但是跨網都是多元的,美國這些公司大了之後,當然不要跟你通,逼著你跟他們一樣,所以當然就會產生這個現象,這就是我們想要避免的,我這樣講您應該很清楚。

  • 傳統以來,我剛剛講說從最早期所有的事情,其實都是在衛福部之下去推,衛福部最近動作也非常快,在 BTC 上,我們從去年就跟他們建議了,他們很認真這件事;但是我們來這裡要問的是,衛福部做這件事的時候,並不會管產業,衛福部通常只想一件事,也就是我們這樣做之後,醫院有系統可以用,策略大概都是比較像採購案。

  • 我在這裡直接講我的看法,衛福部做,常常怕去得罪現在的系統商,所以薛部長講說就整合成四、五個系統,他們有沒有辦法想到比較 high level 的事,我不確定,如果今天我們講產業化,又要避免美國當年犯的錯誤,又要往前走,又要國際化,我想這是施先生找我們來最重要的,我們覺得到數位部來是很重要的。

  • 重要的是,假如是用社會企業,是不是一個好的解決方式?這是施先生很早就問我們這個問題,所以我們稍微把什麼是社會企業定義一下。我們的宗旨:我們成立社會企業,目的是 PPP,要促成的是整個 Health 數位轉型的平臺,建構開放式的平臺,又要接軌國際標準。這句話當然這樣子講,是對也是錯,因為所謂的平臺也沒有什麼國際標準,先做的人就是這樣子,但資料交換當然有一些國際標準。

  • 我們還是很有信心,兩大產業其實都有優勢,第一步可以變成區域醫療發展的系統產品,另外一方面,我們認為還是有機會,所以我們的 vision 還是很大,並不是只做臺灣的。組織還是必須營利,但是又要明訂公益,這是社會企業的本質。原因是我們覺得如果用過去衛福部習慣用的財團法人或者是社團法人,我們覺得社團法人跟財團法人在非營利組織在很多運作上還是有其缺點,是不是公司化比較好?我提這個是疑問,因為我們大家也都沒有經驗。

  • 當然它一定會遇到一個問題,這個公司要永續經營,當然需要一些營收,如果賺太多錢,可能也會是個問題,不賺錢也是問題,所以這個 balance 是困難的。這家公司因為是 PPP,我們會去找國發基金,通常國發基金的態度是民間找到七成,他們就會給三成。

  • 國發基金還有一個積極的角色,公立醫院在法律上暫時不能拿他的錢來投資,所以如果國發基金幫忙投資,我們就可以邀請公立醫院的代表來當我們的董事或者什麼。臺灣三成的病床是公立醫院,公立醫院通常醫院規模大一點,七成的病床是私立醫院,私立醫院的 size 有的很小、有的很大,我們也邀請資通訊界、醫療界、資訊界一起組成,概念上是這樣子。

  • 目標這個是重要的,我們是要協助政府訂定這個標準,而且辦理標準認證,這個是 key,因為其實是一種公權力,當政府做這件事的時候,第一天就已經講說我們要把公權力給這個 PPP 的平臺。

  • 當然,那個是國際標準,所以也不能阻止別人認證?

  • 因為我們有帶著政府的招牌,所以在臺灣一定會有優勢。

  • 雖然沒有獨家,但你是最先動的那個人?

  • 對的。而且我們有一定的優勢,在醫療資訊界本來就是很重要的,是需要訂規則,所以會很多人在看,但我們不需要阻止別人做。

  • 目標是要建構開放式的醫療資訊平臺,等一下會稍微講目前我們的 idea 會長什麼樣子,這個平臺讓大家可以很容易來做 APP,其他的事情當然是所有的教育等等,當然這是必然的。

  • 今天重點其實大家是來交換意見,政府如果認同,數位部是不是對的,如果大家都有這個共識,我們總是要開始去籌組這個公司,但是政府要給這個 mandate。

  • 我先講一下,這是順著上次的討論來的,再請施董事長跟我們分享。

  • 我當時講的是,因為從大家的經驗來看,有些時候還是會說必定要是財團法人或社團法人才適格,但是有些東西可以放開,讓合作事業,以及其他社會事業可以有所貢獻。

  • 先前有些社會企業,是把分潤的股權跟控制權拆開,也就是透過特別股的方式來設計。上面有一個非以營利為目的之組織,是社團或者是財團法人,各界一起組成非營利組織,因為我們是有法人股東制度,上層的組織可以 own 底下這間社會企業的股權。這個看怎麼設計,或許是有否決權,或是一票當作幾票用,但是這個情況之下,投資人不會覺得很像股權被稀釋掉,因為該賺的錢同樣是拿回來。但當這個公司使命開始漂移,上面的基金會可以給他否決掉。

  • 另外,像標準制定、執行認證也是可能的業務沒錯,但是標準制定如果是只有學會、協會才可以做,那就讓上面這個來做,這個是我目前的一些經驗分享。

  • 第一,社會企業對股東的股利發放,未來公司法修法後會有一定的限制,不能超過 3 成。

  • 目前很多是靠章程來寫。

  • 現在很多定位為社會企業的公司,就在公司章程寫明利潤的分法,等立法院三讀通過後就會限制股東的分紅,並把賺來的錢繼續投資在社會企業的服務宗旨方面。

  • 第二,如果開發基金有參與投資,就可以邀請公立醫院的人來擔任獨立董事,就可以在董事會中做決策。因為剛剛鴻仁提到的都是利害相關人,比如資訊界、醫界大家一起共襄盛舉,至於要不要安排特別股,也可以在章程裡面做規範,新的公司法的彈性比較大一點,可以做這些安排。

  • 我覺得不錯,如果上面有一個非營利組織,當作最後有否決權的話。

  • 可以找現成相關的非營利組織來扮演這個角色。

  • 這個都可以。非營利組織那層,就沒有投資型的參與者。

  • 我再去問衛福部的看法。

  • 我先介紹我自己,讓部長認識我,我是一個軟體工程師,我在微軟跟 Google 做了快要 20 年,後來被老闆找回來。

  • 我們一開始不是做 HIS,我們做了一年多的智慧醫療,因為我們覺得智慧醫療是很大的題目,後來為何會去做 HIS?後來因為發現有一個很大的問題,就是開發的部分很複雜,每個醫院的系統都不一樣,這個在我們以前電腦的世界當中,會覺得沒有平臺,怎麼會有 application,因此落地很困難,所以那時一度想要放棄,後來想說做最難的題目,但是很多人跟我們講說這個題目很難,有可能做不出來,但是我們做了一年,透過機會跟大家講說我們現在做到哪一邊,也不見得可以做得出來,但是如果大家一起的話,或許我們的成功機會更大。

  • 透過 AI 的解決方式落地到醫院當中,發現醫院系統有三大問題,第一個問題是各個系統都獨立的,而且非常老舊、客製化非常高,要維護非常不容易,因此要解決這個問題,新的系統一定要能夠 module 這個東西,因為是全部換掉,也沒有人受得了。而且,我們要能夠把稽核的邏輯上千條抽離出來,讓平臺的 code 跟 policy 可以分開,這是我們的大目標,我們還沒有做這個之前,就想說要到底解決什麼問題,要成為 platform,而且把稽核跟 code 分開,我等一下會介紹。

  • 這在金融業的法遵科技早就有了,但是 HIS 目前沒有?

  • 對,我們醫院沒有這個觀念。

  • 更重要的是,沒有人知道 code 在哪裡(笑)。

  • 第二個是 application,因為有 platform 之後,就會想要賦加一些工作,這個是我們想要做的事,所以就開始有一些 concept,也就是希望打造類似 Android 的平臺,只要寫一次就可以給各個醫院用。

  • 第三個是 data,看要如何把 data 有效整合在一起,不只是醫院內部的分享,醫院跟醫院之間的分享,醫院跟第三部門的分享,我們都會透過國際化的方式,讓 data 的 layer 變成一個平臺。這是三個主要的目標。

  • 我們還沒有做之前,就覺得要做到這個程度,現在做到 60%到 70%左右。目前為止假設醫院是這樣的狀況,有 A 跟 B,每個醫院的 database 都不一樣,有的用 200 個 table、有的用 600 個 table,上面也都不一樣,中間的都不一樣,稽核的邏輯也都不一樣,所以導致中間的 code 都完全不一樣。

  • 我們希望用相同的 layer,把 data 放進來,變成 schema 的 model,這就需要大家群策群力,我們從醫院開始做,我相信有更多的醫護進來,把 model 建起來。有 common data model 之後,就可以開始處理 business form,我們希望變成是 no code,讓各個醫院來改變。

  • 我們可以把 rule 分開,上面就透過一堆的 widget 來建構整個 application,下面是 common data model,上面是一堆 widget market,然後各個醫院可以湊起來變成是一個 HIS 的東西。然後 stage、flow 來描述,如果這個做出來的話,我們就有信心可以解決上面的三個問題,從 data 的問題、platform 的問題到 application 的問題,可以一次解決掉。

  • 我們可以把醫院整個邏輯縱向變成是一個個 note,然後就是一個 state chart,這個醫院很簡單,醫生登入、看到病患的清單,然後看到就診的畫面,所以就變成這樣子,如果醫院要改變的話,只要在 chart 當中做一些改變就可以了。像原來的醫院是 login,然後到 patinet list,是一個 JSON 顯示出來,醫院說要在登入之後,讓醫生看到公告的介面,也就是用 widget 畫好,然後稍微改變一下,醫生下次登入就會看到公告的介面,也就是用 state chart 的方式來改變。

  • 第二,data 是希望新舊併陳,很難一次換掉,個是很難的問題,也就是上面新的系統,要用新的 database 來支持它,因為舊的很複雜、很難疏理,所以我們的架構方式是,在上面架一個 database,我們用 MongoDB 來做,但是必須跟新舊中間要有 sync 的機制,然後由這個來設上面的工作,所以有一段時間必須新舊併陳,舊的 DB 跟新的放在一起,然後慢慢逐步改掉。

  • 第二步剛剛已經講過了;第三個是所有的 right,要到 MongoDB,因為其他所有的系統都還是要靠這個才可以運作,這是目前我覺得 HIS 要到新的 HIS 最難的步驟,也就是要有一個轉換機制,也就是開車,但是同時要換速度,但又不能讓它停下來。

  • 我問一個問題,臺灣寫 NoSQL Mongo 的人,以人數來講,是 SQL DB 的零頭,想要採取這個架構的原因是?

  • 因為透過 NoSQL 的方式,我們才可以確認 Schema 是不斷 involve 的過程,你用 SQL 的方式去做,其實會變成很難去發展,所以才會想用 Mongo。

  • 所以你的想像,是上面共通的 Schema 一年可能改了好幾次?

  • 而且改了之後,因為每個都不一樣,就要全部一次更新?然後全部撒下去?

  • 以我們現在的瞭解,醫院的 Schema 的變動沒有這麼高。

  • 所以是上面要動的比底下快?

  • 因為會加上很多的東西上去,好比會有很多的 AIoT 進去。

  • 對,很好。但是要寫回原本的 data store?

  • 如果舊的東西要用的東西,但是如果有的東西是不需要用的,我們就不會寫進去。

  • 但是幾乎都要?因為大概都要出報表,除非這邊可以把所有的報表需求滿足,不然就會每一個更動你都要改。

  • 應該是說如果這個 data 是從這邊拉過來,當然就必須這兩個,但如果是新的 data,我們寫在 xHIS NoSQL Mongo 就好了,但是如果有舊的要用這個 data,我們就會開給他們使用。

  • 理解。假設底下兩年或是四年才動一次,上面打算一年動幾次?

  • 因為下面是很多醫院,上面可以設 common。

  • 對,我講的意思是,上面每動一次,只要有寫入,底下就要動一次?

  • 我指的是需要寫回的部分。

  • 只要有操作的部分。

  • 所以只要有寫回的部分,但如果都不寫回,其實就等於是上層自己開發 APP 而已,也不用動 Schema,那個 APP 自帶 Schema 就好了。

  • 但是我們擔心的是 OPD,其實很多資料是共用的,我們又不想改 IBT,因為那個就要更久。

  • 瞭解。所以你的意思是在說,一開始耦合的範圍你會猜對,然後之後不會再大改,只有依需求再加上去,append only。

  • 對,因為他也要用,我也要用。

  • 這個理解很正確。

  • 部長很厲害。

  • 我們希望逐步的過程中,慢慢這個萎縮掉。

  • 然後一年可以有 12 次,但是每次都是向後相容,就是所有爛掉的部分都要相容。

  • 但是舊的 database 最奇怪對醫院來講,其實就是健保申報,其實說起來也沒有複雜到那個程度,我們新架構,我們想像會有多新的資訊,其實跟未來的智慧醫療有關,因為未來收資訊的那個量,不是舊的系統可以想像的,所以這個地方的整個差別是很大的。

  • 就是平行作業。

  • 這個難度很高。

  • 我就舉一個例子,像現在有所謂的聯邦學習,聯邦學習是各醫院自己拿舊的 DB,上面架了許多外掛,做資料清理,但又要確保個資絕對不能出醫院。但只有 Schema 長得很像,才有聯邦的可能性,不然光是資料清理,又不能看到對方的 Schema,到底要怎麼做?

  • 所以你們這個當然有一個很特別的是,你等於幫他正規化到上面的那個,不管是 Mongo 或者是什麼。但這是你們想像中的一個用法嗎?很像一起來訓練 AI model 的這種用法,我這樣問是因為對大部分的院所來講,我之前在防疫的時候有接觸,他們除非是本來應用層的做法根本不可能滿足的,他們才會想這種樣子,如果加外掛就可以滿足的,大概都會用現有的 HIS 加外掛,他們的廠商也是這樣跟他們講。

  • 所以我在想是不是有全新的,不一定是 AI,但是某種 joint need,但是現在又不可能滿足的形狀。

  • 智慧醫療的未來,攸關上面智慧應用的深跟廣,那個才是決定智慧醫療的未來,但是那個上面的發展不可以受限於 database,所以才要用 common data Schema 才去做上面想像空間,上面的人不要管下面的人,直接去做就好了,這是我們目前想要做這件事的原因,不然其實很辛苦。

  • 如果有這個東西,每個醫院我們只要能夠把這個 layer 融合在一起,上面就可以去做,聽起來很簡單,但是其實很困難,每個醫院都要爬清楚、想清楚,然後放到 Schema,這是很難的工作,所以希望大家一起可以來做這件事,透過公權力或者是醫界,大家一起來做,有這個 Schema 之後,其實上面的事情就海闊天空,不管是對院內或者是院外,其實我們就解決一大部分的問題。

  • 是,這裡我不擔心。

  • 說穿了很簡單,我們希望把 code 分開,希望每個醫院都有所有稽核的邏輯,每個稽核路徑按下去,其實可以用一些方式,讓一些不會寫 code 的方式,都可以用這樣的方式來確認醫院的 rules,我們提供各式各樣的工具來幫助醫院的 IT,或者是第三者來確認這個 rule 跟方式是不是對的,這樣子的話,到醫院的 code,就完全不需要理醫院的邏輯。

  • 最後是上面的 application,我們是把醫院的時間綜軸切成一個一個 note,每一個 note 切成一個小小的位置,像這是就診明細的畫面,我們就切成五個表格,其實只要下面的 common data model 一樣的話,其實 code 寫一份,就可以 run 在各個醫院裡面,因為是 in put 跟 out put,如果 data Schema 都一樣的話,這個平臺的 API 都一樣的話,其實會變成每個醫院不要再重寫了,甚至 100 家的醫院下去,大家先把這個 flow 想清楚,有些 common 的部分,就寫一份,大家就可以拿去用,整合起來就是一個 OP 的畫面,所以把畫面拆成每個表格,然後每個還有 component,然後透過重複大量使用,而且是 common API 的話,就可以 enable。像 ICT 的碼,每一個都要寫一遍,而且還不容易寫,但是未來可能只要有一個 team 寫一遍,這個東西就可以拿出來,當然要付錢或幹麻是另外一件事。

  • 但是本來的操作習慣,我瞭解你有一套設計系統,這個非常好,但大部分的人的習慣是綁在本來設計系統裡面,所以你這個一定要讓它前端,也就是本來廠商有一些事做,弄成本來的 work flow,不然要同時改 DB 跟 work flow,這個可能不實際。這個是不是 web-based?

  • 那這就是另外一個要改的部分,因為有些還不是 web-based,所以一次要改三個地方。

  • 最後是小小的 demo,大家可以看一下,只有 1 分鐘而已。(影片播放)剛剛大家看的是建構出來的門診系統。

  • 我們希望用架構來解決這三個問題,能夠把臺灣的智慧醫療帶到下一個階段,謝謝大家。

  • 剛剛那個影片是我們針對振興醫院去做的,不同醫院有不同的需求,像他們想要看不同的東西跟組合的話,可以拿現有的去改就可以了,大家不需要用同一套,但是可以用同一個 framework。

  • 你們 open source 前,像滲透測試或者是紅隊測試,有做嗎?

  • 內部我們有找人稽核,但是還沒有做這件事。

  • 可能要先做這步。不然你一釋出來就多了好幾個 CVE⋯⋯雖然這其實也是好事,但大概很少人會當作好事。

  • 我們還沒有準備好。其實我們做這個之前,很多人覺得我們死定了,因為很多人說這個很難做,主要的是醫療太複雜了,而且 20 年下來有很複雜的邏輯在每個系統裡面,而且每個醫院都不一樣。

  • 本來既有的,如果加入你是最好,不然可能就會想降低你的公信力,而最快的方法就是資安,所以我覺得這個要小心一點。

  • 這個計畫的利害關係人,從數位部的角度往前看,有技術的方向,衛福部雖然很重要,但還有很多醫院、財團法人或者協會,也要考慮到跟所有利害關係人的聯繫,甚至立法院可能有意見,因為這裡面也許如果要動用純投資,包含國發基金,到了立法院,有時連國發基金的投資,像這種也會有意見,但如果衛福部要做這件事,因為政策要引導,但是以前為了推卸責任,所以委託非營利事業,很像比較沒事,就很像剛剛同仁所講的問題。

  • 以前大部分這種標準、認證都給醫策會,有點像早期的醫策會。

  • 醫策會也是參與這個計畫,到時做好以後,就來融入這個東西,用委員會來做這件事也可以,因此原則上敲定以後,要瞭解到所有的利害關係人,要充分作溝通,因為這裡面會有很多誤解。我剛剛想到還有很多人在這個產業裡面,也就是做診所 HIS 的人。

  • 對,就是醫療資訊的廠商。

  • 那些也會有意見。一定會影響到他們,門也要開給他們,可以說工作轉向,以資訊業來講,徐副董事長也知道,當時停掉電玩,結果這些人就轉做電腦(笑)。

  • 我是沒有做到,但是我剛開始是有看到(笑)。

  • 所以整個政府政策會影響未來的發展,這些人如果有一些更有發展的人,開門給他們走,他們也很高興。

  • 早期做 PC,都是電玩出來。

  • 我們現在除了做振興醫院,也跟健保署做診所,因為診所遇到滿大的問題,當時是希望從大到小都要能夠確認,所以現在也在做診所,希望明年有一些 demo 的東西可以讓大家看。

  • 我們剛剛講兩層,上面是共識層,底下是執行層。共識層你們假設找到利害關係人,有一家廠商出來說捐出來,希望某一層取代你,特別是在健保剛剛講到的法遵那一層,事實上已經做得滿好了,如果他們現在說也 open source 出來,就不用重新寫了?

  • 沒錯,不需要,已經有的人跳出來,就 open source。

  • 就是大家的貢獻,甚至成立一個 pool,一起 license 出去。

  • 我會建議,後面這個技術很棒,但可能講的是 endpoint,也就是最後要達成的那個部分,中間的技術細節,像 MongoDB 那張我建議不要講太多,因為如果他們要捐的話,他們會覺得這個是疑問,他們會覺得難道要改他們的架構嗎?他們覺得那個架構很好等等,那就是不必要的爭論,只要一開始共識的形狀對,最後 endpoint 的形狀對,其實中間用什麼技術,是不是 web-besed 都無所謂,我覺得這個是比較重要。

  • 華碩也是拋磚引玉,沒有說一定要用華碩的,如果這個社會企業成立的話,大家覺得願意接受就接受,不願意接受,我們也推薦回去改,我們沒有說一定要用華碩,我們是拋磚引玉。

  • 你們真正 care 的是下面那個,只要那個有了,上面長好幾套都可以,Android 現在前面的長相有三、四套,但是反正 APP 可以使用就好了。

  • 如果要做下面,我們做上面就可以了。

  • 剛剛提到認證的目標,也就是可以通用,若架構沒有認證好,以後可能會出問題,大家不能互通;像微軟、Android 都有這個認證的程序。

  • 這是一件很大的事情,所以還需要很努力,不過我們在這層觀念釐清,當然下一步是我們還要再回去想說下一步的工作,衛福部如果是這樣的架構,我們就要確定上層的架構是什麼,還有我們這層的架構是什麼,這是第一個部分。

  • 第二,因為衛福部同時在進行一些事,我們希望在進行剛剛不管是次長或者是部長講的,我們希望他在做這件事的時候,他有想到他需要走到那裡,不可以再標一個標案,也就是用舊的架構去更新,這一點我們現在已經說服了衛福部。

  • 現在是誰有能力去接這個標案,就當然會一步步做,因為同時我們在架這個,所以這裡面會有很多事情發生,比如誰來組織跟協調,假設這個平臺會成立這家公司,未來數位部、衛福部的角色,我想都需要部長給我們一些協助。

  • 沒有問題,我很好找,我都在這邊。

  • 如果這個清楚,我們就有辦法往下走。

  • 現在如果衛福部允許部署醫院先行,先當白老鼠,也就是先從這個角度來開標,根據政府的採購法有一定的 rule,到底社會企業可以扮演什麼角色?這個社會企業就是負責制定標準,數位部、衛福部,跟從產業的立場,大家一起參與、把這個標準形成一個共識,至於政府的採購標案,實質上這怎麼樣突破,這可能也要思考一下,讓他們好做事。

  • 所以怎麼樣訂規格標,這當然是整個學問之所在,也就是說,我們今天整個產業界跟政府在一起,可以把規格標訂出來,而且大家認為這樣的規格標符合下一步,我覺得這件事本身就很重要,因為現在開始在想,要把部立醫院拿出來當白老鼠。

  • 政府可以先以規格標來決定參與的廠商,之後訂定評選相關辦法,建立公平的機制,以最有利標由評審委員來打分數,再決定得標廠商。

  • 有點像我們當年在做健保 IC 卡,其實後來健保 IC 卡得標的團隊是沒有經驗的團隊,但是還是做起來。早期曾經有一家公司在澎湖做過,後來得標的是東元,但這個團隊也是新的團隊,我們訂什麼需求規格,其實是重要的,訂這個規格標的觀念也很簡單,我們要把所有的健保卡,用紙卡來做,不過我們當時訂規格的資安訂得很高,所以那時候早期的效率並不是這麼好,您摸過那個系統,您很清楚這部分,但也活過 20 年了。

  • 而且現在網路比晶片讀取快,所以晶片讀取多慢不重要,也沒有東西放在卡裡面了。

  • 這個社會企業本身只負責制定及認證標準,其他的工作都由廠商來參與,因為這個架構裡面,其實有很多廠商,中間是由廠商來當主包,跟有興趣的業界可以合起來,或者是在這架構之後,上面有很多的廠商可以來參與。

  • 是,有可能好比只賣認證、只做輔導,這也是一種想法。

  • 我有跟同仁談過,如果只訂標準及認證。需要的資本額不用很大;但如果要擁有自己的產品,資本額要很大。所以可以考慮由提供軟體系統的廠商,用其產品入股,公司就擁有產品可對外授權,當然這是下一階段的工作,還有待進一步討論。

  • 有點類似 patent pool。

  • 讓他取得一些股權。

  • 社會企業賺的錢只能分 1/3 以下,rule 都有規定,但我們一開始就要由國際市場來思考。我常常跟醫師說電子業賺的錢稍微比你們多,雖然醫師在台灣是一流的人才,資訊電子業是二流的人才,但是我們貢獻比較大,因為我們服務的是全球的市場,相對醫師只服務在地巿場,服務的對象相對有限,貢獻就受到限制。所以如果貢獻能從區域化擴及全球化的話,即使只能分配到 1/3 的利潤,但可能仍比利息高很多,甚至最理想的狀況是,我希望看到臺灣有一個社會企業是上市的,股東分紅雖然受到限制,但是對整個社會能有所貢獻很重要。

  • 瞭解。今天差不多。

  • 你跟薛部長談過了嗎?

  • 我跟薛部長談過了,下一步我們的平臺自己要再談一次,就是 David 要。

  • 下一步包含整個結構性的東西要思考,像委員會的結構性東西要處理,並不是技術的部分,技術反而是徐副董事長處理,本來這就是要 open source,我們就是先把 platform 做起來 open。

  • 下一步說不定施先生也要帶我們再到衛福部去一次,因為部長有講這兩層,這兩層要釐清,非到衛福部去談不行。

  • 這跟國發會應該也有關。

  • 我有找過龔明鑫主委,國發會的立場是,因為他們不是主導的部會,也就是說,只要主導部會政策明確到行政院,他們都會配合行政院的政策,出 3 成對他們來講沒有問題,所以對龔明鑫主委來講,只要是唐部長跟薛部長確定的話,他一定支持,他通常態度都是正面的。

  • 還有蘿蔔跟棍子的問題,政府要有現有的政策環境。

  • 也就是政府要拿出多少誘因,那個公權力在衛福部手上。

  • 對,我們這邊可以幫忙的是,因為你們是 open 的系統,現在當然還是有一些聲音,也就是 open source 的貢獻者除非你都認識、見過面,會不會在資安上混進來,這是很常有的挑戰。

  • 但當然我們看 Android 跟 Linux 的歷史,只要時間夠長、時間夠多,其實往往是更安全的,但是利害關係人要夠多、時間夠長。

  • 而且本來設計加密系統時,就不能假設敵人不知道你的演算法。這雖然在資訊業界是常識,但可能還不到全民的共識,我們這邊可以做的是,如果有人質疑 open source system 的資安如何,我們可以說你們自己已經做過滲透測試、紅隊測試等等,而符合軟體的料件清單的國際標準,其實會更安全,這個部分我們可以出來講,因為我們是資安的主管機關。

  • 就是增加民眾的信心。

  • 對,謝謝。