我覺得是選後。
第3步不太懂，今天一個病患透過打電話去預約，這個是ok的，醫生收到需求之後就給他一個token，也就是給病患一個token，病患還要再打一次電話，然後依照他給我的token去登入哪裡？
所以是口頭授權嗎？我這邊想的是電話要去哪裡登錄？
沒有回報。
健保卡不是證件？
這裡談虛擬卡了，所以可以用身分證。
通常我們會講「證件辨識身分」，不會講證件上的照片來辨識身分。
署內是不是要消化一下這個流程的情境？或者是覺得聽完之後覺得沒有問題的。
署內還是需要時間消化？
我覺得之後過好了，我覺得先給署內瞭解一下情境。
我們先討論一下接下來的做法。
我們現在都在提可能的方案，但是或許可以把這樣的想法到時整理可以放在協作會議當中討論，第一場在協作會議的時候，大家堅持要有實體卡其實是一個前提，要廢實體卡的前提是資料要同步，然後讓就診的醫師可以看到當天或者是這三天就醫的資料，這會是一個放入協作會議當中要討論的問題，如果在協作會議技術上有解的時候，其實剛剛大家討論是不是一定要有實體卡的這一件事，其實就有解套的空間。
第二，剛剛政委提到第一代的實體健保卡去授權虛擬健保卡這樣子的執行時，可以爭取三至四年的彈性空間，可以去發展我們的實體及虛擬間同步的技術，然後再配套去做二代的換發。
剛剛提到大命題的時候，有關於「虛、實併行使用問題」的部分，第一題是有行動憑證是否實體卡無效，我們是不是把這個刪掉？問題是底下有兩個，也就是授權機制的這一件事，這個也是要提出來討論，因為可能是一個很重要的議題。
也包含技術問題。
我可能剛剛沒有注意到，雖然有分三組，但是要分技術、成本、法規，不會一組裡面三種人都有？
加入。
我建議分組。
大家好，我是陳怡君，我是行政院PDIS小組的成員，我今天是被推坑來討論第六組的分組主持人來協助大家討論，我們希望廣收議題的意見，所以我們今天特別邀請了一位已經看不出來八十幾歲的吳媽媽，她代表的是沒有使用手機的族群。
長者可能無手機、不會使用。
可以線上授權給家人。
我們有訂定一個數位服務的發展準則，準則六有鼓勵機關要開發數位服務的時候，能夠評估開源的軟體來做系統的開發，必須是鼓勵，也就是在國內有更多成功的案例，可以給部會更多的信心，大家再朝向這樣的方向發展。
剛剛談到新加坡案例的時候，我們想要瞭解的是，目前跟「GovTech」合作的時候，有沒有考慮從「GovTech」大平台當中，把相關的model帶回去用，可能不同的部會有不同客製化的需求，大家客製化後可以再回饋給大平台，讓大平台可以給其他有類似需求的機關使用，不曉得「GovTech」有沒有這樣的機制或者是規劃？
新加坡資訊組織的組成跟臺灣不一樣，因此他們發展政策上來講不一樣，會採取機關的選擇，所以處長提到臺灣很多系統開發的部分，其實都是跟SI廠商來合作。我知道資策會有一個team輔導機關朝開源的方向來發展，之後有機會也可以跟資策會的team來交流，可以來合作以啟動臺灣未來的可行性。
接續剛剛政委提的建議，其實繁體中文滿重要的。
因為政府的採購上來講，會希望政府機關所採用的產品盡量沒有國安上的問題。
所以，如果今天機關在survey，從紅帽的網站上看不到繁體中文來講，疑慮度會增大。
我剛剛也有跟資策會的同仁聯絡，像剛剛政委講的team，我可以給您他的聯絡方式，也許後面你們就可以自行瞭解。
要求讀卡的速度？
如果排早上的話，可能上午不能排會議，如果只抓下午的話，也許還可以。
大家好，我是司法院公關處，我是怡君，我是負責司法院的小編。
對，7月底可提供Beta版。
我已經認真漂白了。
目前會發展check list的部分，引導政府機關以數位服務生命週期，從需求探索、開發至後面的上線，還有到後續怎麼永續營運的部分，這些階段的過程中，如何用key question的方式來協助機關規劃。
剛剛談到是RFP怎麼寫，我們目前就RFP的部分沒有範本，但是我覺得可以把服務準則的需求納入，將來甲、乙雙方都共同用準則，包含準則的條文、check list的方向來規劃。
不管文字再怎麼規劃，重點都在於甲、乙雙方如何對需求來作確認，而這個確認，一開始寫得很寬鬆，後來寫得越來越細，是因為要提供廠商分析成本，評估投入資源，所以規劃當中，要跟政風、主計及秘書單位多一點討論，才能把標案的程序設計得更好。
也可能不小心來了，但是後來發現是誤入叢林的小白兔。
會需要一些更多的範例（笑）。
沒有根據條文來做規範設計，應該先探索服務設計的樣態發展的模式及所以現在做的是「數位服務準則」的規劃，包含key question的設計，包含張芳睿及Mark分享就不同機關服務的過程，像報稅軟體的改善，還有現在跟健保署的二代健保卡如何研議的過程，其實這些都是不同的案例。
是，我分飾多角。
我可以試著找找看，包含在工程會、資策會也有做一些範本，但是這樣的範本，可能比較過去開發方式的範本，比較不是現在在談的這一種敏捷式開發方法、服務設計的範本。
你的可以給我們當範本（笑）。
我們試著找之前的範本。
報稅軟體案就像政委所講的，提案者本身就是真的有設計能力的人。
健保卡案的Persona，醫療院所端我覺得比較好找，使用者端這邊的個案，還是需要給健保署一些協助。
工作坊規劃部份，財政部應該有很完整的資料可以參考。
大家好，我是國發會陳怡君，非常希望大家今天能夠多給我們意見，謝謝。
我補充一下，從準則二就可以看得到，定義服務生命週期是包含設計建置、維運，這整套是生命週期，在生命週期的過程中，都需要包含了瞭解使用者需求等程序，又或者是準則6，必須評估生命週期各階段使用到的工具系統等等，也就是生命週期在準則2這邊下一個定義，在過程當中的每一個階段推動的做法，可能都會需要用到準則裡面的各項來實作，這是我們當時在討論準則的想法。
我想回應這個問題，並不是把所有的服務都只提供數位化服務而已，我們覺得提供多元的管道，才能更便利。
做數位服務準則的過程中，我們看到的是，臺灣現在希望推動的是數位政府的轉型，而最開始的起步就像林老師所講的，這份準則只是數位政府轉型或數位服務轉型的一小步，但改變的是公務機關同仁的觀念，我們會希望這份準則扮演的是這樣的角色。
