應該在這次 COVID-19 大流行中學習的額外教訓，除了比爾蓋茲的建議以外 – (5)

This is the Chinese version. For English version, click here.
這是此文章的第五部分，閱讀上一部份請按此:第四部分

6. 記錄國家人口

---

比爾蓋茲在他的書中指出，一些國家不進行出生和死亡登記來準確地記錄其人口。他說，“他們中的許多人 (低收入和中等收入國家) 使用相隔數年的家庭調查來估計出生和死亡人數，這代表著他們沒有準確的數據”。他進一步地指出，“最起碼的情況下，許多低收入和中等收入國家需要更強大的出生和死亡登記，這些訊息將為國家疾病監測工作提供訊息”。

確實如此。例如，中國在記錄出生和死亡方面存在著嚴重的問題。根據中國人民大學的研究，2020年中國的死亡率為10.07%，出生率為18.38%。這兩個數字都高於 2019 年的水平，與中國呈日益下降趨勢的出生率、死亡率嚴重不符。研究指出，上述嚴重偏差可能是由於七普數據採集方法的不同，即用七普方法採集的人口數據存在大量少報、漏報的嫌疑。該研究還指出了與比爾蓋茲描述的相同的問題 — 中國的人口、出生和死亡人數來自抽樣調查和基於該調查的估計，這使得人口數量不準確，並有可能政府故意少報出生人數 ^[1]https://zh.wikipedia.org/zh-tw/中华人民共和国第七次全国人口普查  ^[2]https://web.archive.org/web/20211101150221/http://pdsc.ruc.edu.cn/jdjx/55f514b5aa1a4f6397f535dc762438b0.htm#:~:text=由此推算2020年,出生率、死亡率严重不符%E3%80%82 。

這個問題必須解決。我建議中國政府不僅要開始做好出生和死亡登記工作，還可以把登記工作進化到遠遠超過目前許多國家所做的登記工作的程度。例如，美國和台灣都需要出生證明才能為新生兒登記^[3]https://www.parenting.com.tw/article/5087398  ^[4]https://www.usbirthcertificates.com/articles/birth-certificate-baby 。中國也是這樣做的 ^[5]https://baike.baidu.com/item/户口登记/2492270 。然而，中國有發生一些拐賣嬰兒/兒童的案件，這些案件是關於人口販子將他們綁架的嬰兒/兒童賣給希望生小孩但沒有小孩的中國家庭 ^[6]https://www.hk01.com/即時中國/649746/失孤-原型尋子24年走逾百萬里終團聚-劉德華拍片祝賀 。一種可能性是出生證明的要求並沒有被恰當地執行。如果出生證明的要求執行得當，在我看來，購買這些孩子的中國家庭有可能是成功地使用假出生證明來登記戶口，這是一種多報人口的案例。雖然整體上中國拐賣事件的數量可能不會影響 2020 年出生/死亡率與 2019 年出生/死亡率的差異 – 可能同時存在少報和多報的情況，但少報人數超過多報人數，但中國拐賣事件是中國出生登記工作(或戶口登記) 並沒有被恰當地執行的後果之一 。

那麼如何解決這個問題呢？首先，中國政府必須找出問題所在。現在沒有個一個家庭是如何幫他們購買的嬰兒登記戶口的解釋 — 可能是因為在閱讀相關販賣兒童事件時沒有人想到這一點；出生證明的要求仍然是有可能沒有被正確執行。如果是這樣，那就好好執行吧 — 很多心碎的父母就都能把孩子找回來，部分的多報問題也能得到解決。不過，如果問題是家庭使用假出生證明來幫他們購買的嬰兒登記戶口，我建議在出生證明上添加防偽功能，就像身份證上的防偽功能一樣。美國和台灣的出生證明都不存在防偽特徵。添加這些功能是將出生登記進化到遠遠超過許多國家目前的狀態。我也建議中國政府考慮讓出生證明更加先進，例如，將出生證明數字化並附上晶片。這種方式不僅可以防止偽造證書，還可以提供其他好處 — 例如，可以在數位出生證明中添加數位化的DNA記錄。

將具有防偽功能的出生證明數字化會阻止許多想要購買小孩的家庭實際購買一個小孩 — 如果他們無法為小孩報戶口並讓他們能夠上學，那麼撫養小孩將在一定程度上變得毫無意義。如果解決了被拐賣兒童的戶口登記問題，不僅出生人口數字可以更加準確，許多令人心碎的失去孩子事件也不會再發生。

7. 給民眾使用的關於大流行病事務的數位平台

---

比爾蓋茲在他的書中討論了與流行病數字平台相關的幾個問題，如下(1)至(3)點所簡述。 我將在第(3)點中添加一些額外的問題，並針對所有三點包含額外的問題提出我的建議。

7.(1) 語言障礙

比爾蓋茲：“建立一個可以預約檢測的平台，創造人們可以報名和處理他們的樣本的網站只是挑戰的一部分……確保結果反映實際社區構成完全是另一回事。並非每個人都可以輕鬆瀏覽網站。語言障礙可能會阻礙他們。當對測試工具組的需求很高且供應有限時，可以待在家裡反覆瀏覽網站的人比仍然需要去上班的基層員工更有優勢。”

7.(2) 將監管報告標準格式化和放在雲端上

比爾蓋茲：“我希望看到的另一項創新是將監管報告放在雲端上並採用標準格式，以便全球所有監管機構都可以對它們進行審查，而不會重複。尤其是在美國，採用標準格式進行患者的健康記錄將有很多好處，包含更容易找到潛在的藥物試驗志願者。”

7.(3) 過時的軟體

比爾蓋茲：“公共衛生機構沒有得到應有的公眾關注或政府資助 — 在州等級（包括美國）、國家級或世界衛生組織的全球等級都沒有。” 他進一步說，“2021年，微軟與美國的一個州的衛生部門合作，該部門的軟體已經有20年的歷史了。”

台灣也有類似的問題。一開始，我以為是台灣才有的問題；對於美國這樣的高度發達的國家來說，它提供給衛生專業人員和普通民眾的軟體一定是最新的。直到讀了比爾蓋茲的書，我才開始知道美國也存在這個問題。不管怎樣，讓我們也談談台灣的問題是什麼。一位立法委員鄭麗文女士批評了我們的 IT 政委唐鳳的平台，這位 IT 政委唐鳳是一位受人尊敬的工程師，根據維基百科，唐鳳為蘋果提供諮詢服務。立委鄭麗文批評說，“IT天才所做的每一個平台，慢半拍、上線永遠大烏龍，隨便一間坊間工程師做的都比唐鳳強幾百倍”。她所說的平台上線時出現的問題是，一個登記疫苗意願的平台在210萬人在線時崩潰^[7]https://www.cna.com.tw/news/firstnews/202107135009.aspx 。立委鄭麗文進一步表示：“一個很簡單、根本沒有什麼技術難度的平台，非得要拖到天荒地老，最後終於上線了，又出現一大堆烏龍跟錯誤！我們要拿這個東西去跟人家講說，台灣是科技大國嗎？” 然而，鄭麗文的想法遭到了批評。很多台灣人表示：“妳真的懂技術嗎？不懂，妳憑什麼能批評專家做的平台？”、“我今天上網登記意願 花不到三分鐘吧”、“頻寬、流量，主機效能對應使用人數。鄭麗文肯定搞不清楚才敢這樣說”……等等^[8]https://today.line.me/tw/v2/article/wD1gXE?utm_source=copyshare 。立委張博洋也批評說，“鄭女士可能從來不買演唱會票” ^[9]https://m.facebook.com/story.php?story_fbid=1835849306588394&id=1141695282670470&anchor_composer=false。

哪一邊是對的呢？ 反對鄭麗文對唐鳳平台的批評的那一方看起來是有道理的。 然而，我同意鄭麗文的意見； 平台很爛。 讓我解釋一下為什麼。

7.(3).1 流量

贊同立委鄭麗文批評的人說：“這種專科生程度的系統，不知道要花多少納稅人的錢？” 有人回答說：“你有辦法找個專科生搞出個可以承受每秒1萬個請求的系統？^[10]https://today.line.me/tw/v2/comment/article/wD1gXE”。嗯，我懷疑流量不是每秒10,000個請求。讓我們來看看實際數字。在一次當機事件中，每分鐘 6000 人上線；這等於每秒 100 個請求。因為平台當機，所以新聞標題是 “疫苗登記大塞車！健保署: 1分鐘超過6000人擠上線。^[11]https://www.ettoday.net/amp/amp_news.php7?news_id=2029533 ” 在另一次當機事件中，它是每分鐘 30,000 人；這等於每秒 500 個請求 ^[12]https://www.setn.com/news.aspx?newsid=953064 。兩個事件都不是每秒 10,000 個請求。我懷疑說10,000個請求的人並沒有實際去計算過，甚至不知道如何計算這類事情。

每秒處理 500 或 100 個請求是否困難？一位台灣人抱怨系統很糟糕，因為系統應該要能夠處理這樣的流量。另一位台灣人計算結果為每分鐘 22,222 人，相當於每秒 370 次請求，但有人抱怨說：“你是不是沒開發過網站啊？你覺得要做這套系統很容易嗎？平均每分鐘至少有 22,222 人喔 (每秒 370 人)。” 另一個人回答說：“如果平台處理不了那麼多流量，為什麼要讓這麼多人同時使用平台？”。原本發文抱怨的人又提供了另一個論點來反駁處理此類流量“不容易”的言論，他指出，“五月天 (一個台灣搖滾樂團) 55萬張演唱會門票在9分鐘內售光。平均流量為每分鐘61,111請求 (每秒 1,018 個請求) ^[13]https://www.setn.com/m/ampnews.aspx?NewsID=610044  ^[14]https://www.dcard.tw/f/trending/p/236475848 。” 我同意這個人的觀點 — 演唱會票卷平台的開發者可以讓平台能夠處理更高的流量，但政府的疫苗平台做不到，所以很爛。此外，對於政府不應該讓這麼多人同時使用平台這一點，很多台灣人表示贊同，並表示問題在於疫苗平台的開發者沒有做壓力測試和計算。準確地估計可能的流量。開發該平台的公司工程部也表示，是因為他們對流量的估測太低，所以沒有購買足夠的伺服器。

然而，在我看來，這不是一個好原因。

第一，這是一個眾所周知的事實。如果你第一次沒有注意到要計算潛在流量或不知道如何計算潛在的流量，然後你在第二次2021年7月時沒有透過審查所有可能的方面來預防當機，那為什麼2022年1月還在發生當機呢^[15]https://www.ettoday.net/news/20220115/2169708.htm ？我認為開發供應商的能力有著很大問題。

第二，接種順序在當時已經確定並公開，台灣有多少人口是已知事實，台灣有多少人口按特定順序合格也是可以計算出來的已知事實，準確的估計應該不是那麼困難，特別是因為流量只有每秒500個請求。

第三，這一點會有點技術性，但請跟著我。你可以只理解後面非技術的部分就好，而不必理解完整的部分。好的，讓我們開始吧。平台當機了很多次，不止一次。開發供應商第一次說他們沒有購買足夠的伺服器。第二次廠商說伺服器夠用，但是流量超過了前端閘道負載。我不確定，但我假設 “前端閘道負載” 是指前端負載平衡器(front-end load balancer)。問題來了：是負載平衡器(load balancer)還是 Instance 無法處理此流量？無論如何，它是負載平衡器(load balancer) 還是 Instance 都沒有關係。負載平衡器(load balancer) 或 Instance 可以根據實際使用量計費，或可以根據CPU和頻寬有多種選擇來處理相對應的流量^[16]https://aws.amazon.com/elasticloadbalancing/?nc2=type_a ^[17]https://aws.amazon.com/ec2/instance-types/ 。接下來非技術但重要的部分來了。第一次是沒有買足夠的伺服器；第二次是沒有買足夠的負載平衡器(load balancer) ^[18]https://www.sumologic.com/insight/aws-elastic-load-balancers-classic-vs-application/  / 買錯負載平衡器的類型 / 選擇了錯誤的、無法處理高流量的Instance類型。供應商很可能是 “頭痛醫頭；腳痛醫腳 (一個表示這是一種零碎的方法的中國諺語）”，但並沒有有經驗的、且全面性的審視如何在已知道潛在流量有多少時預防當機。

雖然五月天演唱會記錄的證據很清楚，但認為系統“不爛”的人仍然不相信，堅持自己的立場。其實，已經有很多人說 “演唱會門票、雙11的淘寶網……等等，這些都經歷了大流量且沒有當機”；然而，很多人並不相信這個平台很爛。為什麼呢？因為他們沒有提供他們舉出的例子的實際數據，像五月天演唱會的例子一樣的數據。許多人的伴隨著例子的論點並沒有提供實際數據。如果是我，我會想，“演唱會票卷平台或雙十一期間的淘寶流量真的比疫苗平台的流量高嗎？” 在提供數據之前，這仍有待驗證。儘管如此，即使拿出了五月天演唱會記錄的證據也不相信平台爛的人是錯誤的— 既然有數據，他就應該相信。

儘管如此，對於即使已呈現數據也不相信平台很糟糕的人，讓我提供另一種觀點。即使沒有來自其他平台的數據，處理此類流量並不容易的說法仍然值得懷疑。每秒處理 500 或 100 個請求是否困難？我不是軟體工程師，但在我看來，每秒 194 個請求似乎很低，對於專業的工程師來說應該沒什麼大不了的。依我之見，即使是每秒 500 個請求對於專業工程師來說應該要不是什麼大問題 — 更不用說可憐的每秒 100 個請求了，但新聞的標題是“疫苗登記大塞車！” 。很多工程師都同意了，其中包括一位畢業於台大 (一間台灣頂尖大學) 的人。看起來每秒 100 個請求的流量對於一些台灣工程師來說似乎很困難。不管如何，如果你不相信我，五月天演唱會門票每秒 1167 個請求記錄的證據足以證明處理每秒 100 個請求對於專業的工程師來說不應該是什麼大問題。事實上，每秒 1000 多個請求的流量對於許多平台來說都是基本的。Adele在英國的演唱會門票 65,000 張在1分鐘內售罄，相當於每秒 1,083 個請求 ^[19]https://metro.co.uk/2021/10/30/adele-fans-gutted-as-bst-hyde-park-concert-tickets-sell-out-in-minutes-15512995/  ^[20]https://www.billboard.com/music/music-news/adele-bst-hyde-park-festival-performance-1235110245/  ^[21]https://www.thesun.co.uk/tvandshowbiz/16581318/adele-tickets-british-summer-time-hyde-park-sold-out/ 。 在最快銷售的產品排行榜上，EXO在韓國甚至在 0.2 秒內售出了 66,000 張門票，即每秒 330,000 個請求 ^[22]https://en.wikipedia.org/wiki/Talk%3AList_of_fastest-selling_products 。在中國的雙十一購物節，阿里巴巴一秒接到58.3萬個訂單，即每秒 58.3 萬個請求。 Google每秒處理 40,000 個搜索(請求)^[23]https://www.quora.com/Google-processes-40k-searches-per-second-On-average-a-web-server-can-handle-1000-requests-per-second-Does-that-mean-Google-can-run-using-only-40-web-servers 。 Twitter每秒有 70,000 次 API 呼叫 ^[24]https://techcrunch.com/2010/09/17/twitter-seeing-6-billion-api-calls-per-day-70k-per-second/ 。相反地，我們可悲地在這裡爭論每秒 100 個請求是不是很困難 ^[25]https://www.bnext.com.tw/article/60038/double-11-tmall-alibaba-2020 。

你說這是因為他們是大型科技公司？讓我告訴你為什麼這個原因沒用。

第一，疫苗預約平台是一個來自政府的平台。政府的工作應該要比大多數小型軟體公司做得更好。除非我們在一個貧窮的國家，否則政府應該要有足夠的資金雇用優秀的工程師並支付足夠的伺服器成本 — 而且我們確實有，我們有 2 億(台幣) ^[26]https://www.youtube.com/watch?v=rDbbxhsHiIA 。

一個額外註解，很多人會認為，也許 2億(TWD) 對於這樣一個平台來說確實不夠；也許該平台需要工程師大量的人力工時投入來完成。

好的。我的觀點有兩點：

首先，以我曾經在一家小型軟體廠商公司工作的個人工作經驗來看，一些小型軟體廠商從規劃設計介面到軟體開發，製作一個軟體只需要幾百萬美元 (單位:TWD)，而一些軟體廠商所設計的介面，包括我工作過的那間，都更漂亮。這價格不包括伺服器和維護成本，但即使考慮到伺服器和維護成本，2億也應該要足夠了。不管怎樣，這點只是根據我個人的經驗來判斷。或許台灣更多的軟體廠商可以說出2億是否夠他們做一個這樣的平台，包括設計和與醫院平台的整合。

其次，根據builtin，美國軟體工程師的平均年薪為$120,039 美元，即 $3,721,209 台幣。如果我們一年雇用 15 名工程師，工程師的總成本是 $55,818,135 台幣，僅佔2億預算之約 28%。鑑於開發軟體的主要成本只有人力資源和伺服器此類雲端費用，即使疫苗平台複雜得多，需要更高的伺服器成本，2億也應該足夠做一個至少可以處理1000+請求的網站每秒請求，配上足夠多的伺服器，還有最重要的是，為老闆留下足夠的錢為他自己賺取利潤。但平台無法處理這樣的流量；疫苗接種平台甚至沒有與許多醫院的平台整合。在我看來，2億的價格應該包括與許多醫院平台的整合工作，但它沒有。

你說只有像Google這樣的大型科技公司的工程師才能勝任這工作，而且他們的薪水高於一般工程師的平均薪水？這是一個藉口：第 1 點，我已經將我的要求降低到每秒 1000 多個請求的流量，而不是Google或Twitter處理的每秒 40,000 或 70,000 個請求 (實際上，他們之中的大多數人可以處理更高的流量)。而且，與外部系統整合是許多一般(普通)美國工程師所具備的技能。如果你做不到，而且你是一名軟體工程師，那是你的問題。第 2 點，根據Glassdoor，美國Google軟體工程師的平均年薪為$205,547美元，即 $6,371,957 台幣。即使你需要雇用Google級別的工程師，招聘 15 名Google工程師的總成本為 $95,579,395 台幣，大約是 2 億預算的50%。我不知道，1 億 (50%) 應該足以購買足夠的伺服器來處理起碼每秒 1000+ 個請求的流量，並且至少會有剩下一點錢讓老闆為自己賺取一些利潤。

我希望這些數據足以讓你知道，2億(TWD)確實足夠擁有一個可以處理1000+個請求流量的平台，即使不考慮有關於我個人經驗的第一點。

第二點有關於我針對為什麼 “只有大型科技公司的工程師才能處理高流量的論點“ 不能是理由的回答是，我認為台灣可能確實有一些優秀的工程師。即使台灣工程師的平均水平無法與 Google 或 Facebook 競爭，他們應該 “至少” 能夠處理每秒 1000+ 個請求的流量。如果大部分的台灣工程師處理不了這樣的流量，那是大部分的台灣工程師需要加強能力的問題，因為西方公司的許多工程師能夠處理更高的流量，並且疫苗接種平台仍然很爛。我不知道是不是大多數台灣工程師都無法處理這樣的流量，但可以肯定的是平台很爛。

*註：伺服器成本計算 — 以此例子為例判斷，每年處理 2300 萬用戶的成本為 $1,283,400 台幣，僅佔 2 億預算的 0.6%。雖然每個平台的情況都不一樣，但是雲端成本和每秒1000+個請求的流量需求，大概佔不了多少預算，更不用提平台連每秒 100 個請求的流量都處理不了。不管如何，我不是 DevOps 方面的專家，我也不知道此平台在例如伺服器等雲端費用上實際花費了多少。或許政府可以向公眾提供實際分解項目的成本和相關數據，以便技術專家或經驗豐富的工程師判斷雲端成本是否合理，以及平台的 DevOps 管理是否有問題。

雖然比爾蓋茲只有談到美國一個州的衛生部門升級軟體的需求，但美國其他地方也遇到了同樣的問題。在美國，聯邦政府讓州政府自己想分配疫苗的方法。華盛頓州開發了一個網站，當超過 36,000 人在線時當機了 ^[27]https://www.cna.com.tw/news/firstnews/202103170290.aspx 。再一次補充，一開始，我認為這是一個只發生在台灣的問題，但現在我意識到，當美國的大型科技公司(如Google) 可以做得更好時，美國卻也有同樣的問題。回到主題，雖然我不知道這36,000人的實際時間區段，但技術專家Raphael Lee表示，“當 37,000 名用戶試圖訪問這種規模的網站時，任何網站都不應該崩潰。” 他說道， “這些數字並沒有那麼大 ^[28]https://statescoop.com/washington-dc-vaccination-website-crashes/ 。” 並且，據《華爾街日報》報導，美國之所以出現低質量平台的原因是，當聯邦政府讓各州自己想出分配疫苗的方式時，州政府往往資源不足。 “各州資源不足，不一定有資源建立網站來支持疫苗的推廣” ，專家約翰布朗斯坦說^[29]https://www.wsj.com/articles/health-officials-scramble-to-provide-booking-systems-for-covid-19-vaccines-11610488516 。我想讓你知道的是，至少美國人承認這個平台很糟糕，那裡有技術專家說它確實很糟糕，而美國問題的根本原因是地方政府資源不足。相反的，很多台灣人不願意承認我們的平台很爛；沒有技術專家現身發聲，並且台灣政府有足夠的資金和資源做一個像樣的平台，但台灣政府並沒有真的做一個像樣的出來。

回到一些台灣人的疑問，你們中的一些人認為立委鄭麗文不是技術專家，所以她不應該批評疫苗接種平台嗎？我想知道為什麼只有技術專家或工程師才能發聲，因為這個平台確實糟糕到即使是非技術人員也應該能夠察覺到。雖然我在這個話題上講得更技術性一點，但我也不是工程師。世界上有很多人需要專家來批評一個特定的話題，否則他們會認為“你他媽的以為你是誰？” 在我看來，沒有必要一定要是相關專家來批評一個特定的話題；沒有必要一定要是技術專家或工程師來批評一個平台。他們可能在如何改善他們所批評的問題上無法提供適當的建議，但他們仍然可以批評一個平台或一個特定的話題 — 只不過是普通人很難判斷批評是否合理，而且大多數時候是專家發現問題並提供批評。這是我希望讀到這篇文章的每個人都能學到的一點。此外，一些美國技術專家在疫苗接種平台事件後發聲，但在台灣沒有這樣的專家發聲，包括在Google台灣子公司工作的台灣工程師也沒有發聲。希望日後有任何針對台灣政府科技議題的批評時，台灣的科技專家和有經驗的工程師能主動公開發聲，發表自己的看法。即使你不是著名的工程師，你也可以說：“我是工程師，如果有[多少]也能達到這個要求的人和我一起工作和足夠多的雲端費用預算，我就能達到這個要求”。台灣媒體也需要去採訪一些科技專家，詢問他們的觀點。雖然有一家台灣電商服務公司91APP ( 唯一一家在雙十一期間經受住巨大流量的台灣電商 ^[30]https://buzzorange.com/techorange/2018/11/15/how-does-91app-deal-with-1111/  ) 根據91APP的CPO的一篇文章所述，91APP可以在 8 分鐘內處理 800 萬條推播 — 每秒 16,667 個請求，這很棒 ^[31]https://medium.com/retailscience/2020雙11觀察報告-46625a79e049 ，但台灣的另一家主要電子商務公司 Pchome 可能甚至無法處理更小的流量。 根據報導由於Pchome的流量增長了10倍，系統出現異常的此新聞，Pchome的平均流量為每月 3244 萬次 ^[32]https://www.top10.com.tw/life/938/top-10-online-shopping-website/ ，約為每秒 12.5 個請求，雙十一期間流量是平時的10倍 ^[33]https://udn.com/news/story/7241/5884010 。假設平均流量為平常的每日流量，經計算，則雙十一期間Pchome每秒處理 125 個請求的流量。如果台灣的大公司連每秒 125 個請求的流量都處理不了，那台灣工程師的大部分能力可能也處理不了這樣的流量。如果是這樣，難怪沒有人跳出來說 “如果有多少人跟我一起工作和足夠多的雲端費用預算，我就能完成這個流量要求”。

不過，台灣媒體還是要採訪科技專家，詢問他們的觀點。你知道的，這樣才能知道普通台灣工程師的真正能力。

有一位台灣人還有一個擔憂：國家健保局的 API 驗證可能無法承受如此高的流量。如果這是真的，是的，這個當機問題的責任將不屬於開發供應商。然而，此問題將成為國家衛生和福利局開發此 API 的工程師和政府的問題。由於這是一個全國性的系統，因此這些工程師的工作應該要是開發能夠承受高流量的 API，並且答案仍然是一樣的：疫苗接種平台很爛。 無論如何，問題是關於前端閘道的流量，供應商已經解釋過。所以這應該不是國家衛生和福利局API的問題。

7.(3).2 與醫院系統整合

一位台灣人指出，開發一個疫苗接種網站花了很長時間。 與當地衛生局、醫院和診所的系統整合應該已經花費了很多時間。 然而，根據康健雜誌的一篇文章報導，當有消息稱疫苗預約網站是一站到底完成預約時，疫苗預約網站在那時尚未與醫院系統整合。 許多完成預約接種的民眾查詢了醫院掛號系統，但發現醫院掛號系統中沒有預約資料。 台灣人問：“那麼請問(開發供應商)這陣子都在忙什麼？^[34]https://www.dcard.tw/f/2019_ncov/p/236475248 ” 另一位台灣人在另外一個網站反駁了同樣的抱怨，寫道，“每家醫院掛號系統都不一樣，政府要怎麼(與所有系統)整合？” ^[35](https://www.ptt.cc/bbs/Gossiping/M.1626153064.A.9FB.html

這是個很好的問題，與台灣所有的醫院系統整合是一項艱鉅的任務。根據衛生福利部的數據，台灣大約有17個地方衛生局和479家醫院 — 也就是496個系統，確實是一項艱鉅的任務 ^[36] … Continue reading。然而，該平台的開發供應商並不需要為了跟所有的系統整合，而整合 496 次；供應商只需開發為在醫院工作因此負責維護醫院系統的工程師提供預約數據的API；這是為個別醫院工作的工程師們的工作，他們要去呼叫供應商開發的 API 來獲取預約數據，並讓數據自動且即時的記錄在他們的醫院系統中。因此，廠商只要開發並公布平台的API就不需要做整合，並且每間醫院的工程師只對他們負責的系統做整合，因此只需要整合一次。 (順帶一提，我差點同意有很多系統要整合的這種擔憂並被混淆，因為我已經遠離軟體議題很長時間了。)

政府也需要與醫院討論大多數醫院可以接受的正式API欄位。有些人會問，有些醫院想要這些數據、有些醫院想要其他類型的數據……這很難處理。這可能是許多醫院管理層和台灣工程師都會提出的問題。所以當我們遇到這樣的問題時，我們就放棄了嗎？

不，在我看來，這不是問題。 這些API欄位不必適用於所有醫院；適合大部分醫院就夠了，剩下的是各間醫院自己的事。為什麼呢？因為只要醫院有病人的健保卡卡號，醫生應該要可以通過該卡號獲取患者的相關數據，包括用藥記錄，這正是他們所需要的。姓名、出生日期、健保卡卡號、電話號碼 — 這些都是需要提供給醫院的必備數據，但對於有一些醫院需要獲得而其他醫院不需要的一些數據，這是需要這些數據的醫院的問題。確定需要哪些類型的數據實際上很簡單：只需提供健保局在進行審查時需要檢查的所有類型的數據，並另外添加電話號碼作為所需數據之一 — 這些數據肯定已經包括姓名、出生日期和健保卡卡號。唯一需要添加的數據是《醫師法》第 12 條中未列出的電話號碼 (所以我不確定電話號碼是否是強制性應紀錄的，但應該是強制性的)，以便醫院或診所可以聯繫患者當他們需要的時候。

醫院的整合工作依然會是困難重重。為什麼呢？因為許多醫院仍在使用過時的網站為患者進行預約，從許多過時的醫院網站的現狀來看，它們過時的原因要麼是目前負責這些系統的工程師缺乏最新的技能，要麽是醫院缺乏資金對其網站進行更新，或兩者皆有。因此，如果問題是醫院的工程師缺乏最新技能，那麼這些工程師可能也無法勝任整合工作。那整合工作可能需要落在疫苗平台開發供應商的頭上，這可能會引起一些頭痛。還有一種情況是一些醫院將網站的開發外包給了軟體商。如果這些醫院缺乏資金要求他們的供應商進行整合工作，那仍會是一個問題。然而，為醫院節省大量人力資源來獲取數據或節省患者在預約上的精力而開發 API 仍然值得，並且開發API仍然是當前與各種系統整合的最佳解決方案。

需要注意的是，開發供應商當時似乎沒有想到要開發API — 可能是因為工程師們缺乏經驗。疫苗接種平台似乎在那之後完成了整合 (只是整合工作應該在平台推出時完成，但當時並沒有。) 然而，根據康健雜誌，當醫院打電話給衛生局詢問有關於一站式預約平台時，所有衛生局都一頭霧水。他們說：“也就是唐鳳系統預約了，就算掛號成功了嗎？還是要再掛一次醫院的號？沒有人搞得清楚。^[37]https://www.commonhealth.com.tw/article/84651 ” 從字面上看，醫院和地方衛生局似乎對整合工作一無所知。那麼整合工作可能不是透過開發 API 和讓醫院與當地衛生局的工程師來做整合工作。因為如果是這樣的話，醫院和衛生局就不應該有 “公民還需要在醫院的網站上預約嗎？沒有人能看出來” 這樣的困惑。— 這句話看起來好像他們都以為整合工作應該要由唐鳳的廠商來做。如果整合工作確實不是透過開發API來做的，我就想問為什麼連唐鳳這樣一個軟體專家，都沒想到要開發 API 並將此作為與496個系統整合的解決方案。使用API進行整合是軟體產業很常見的做法，作為“軟體”專家的唐鳳應該要知道。許多軟體工程師已經有在他們的工作中或 Side Project (下班後的個人專案) 裡使用過 Google 或任何一間大型科技公司的 API — 你可能也使用過其中一種 API。如果使用 Google 的 API 對你來說是一個陌生的話題，這裡有另一個例子：很多台灣工程師使用 LINE 的 API 開發機器人作為他們的Side Project；你們中的許多人應該很熟悉這個舉例。不管如何，後來疫苗接種平台和很多縣的平台都和醫院平台整合了。我不知道開發人員是如何做到的，我只是根據新聞中的文字猜測。上面幾段只是有兩個目的：一是回答 “每個醫院系統都不一樣，政府如何整合它們？”的問題。二、既然開發 API 就可以與496個系統整合，一位台灣人在這平台的整合工作確實沒有完成的時候抱怨並質疑 “為什麼花了很長時間開發一個平台，但整合工作還沒有完成” 是合理的。

除了開發 API 作為解決方案，還有兩點需要注意。第一，即使我們假設世界上沒有 API 這樣的東西，開發供應商必須自己整合 496 次，供應商不是同意這樣做嗎？就算供應商預估的完成時間過於樂觀，他們不應該至少完成與當地衛生局或少數間醫院系統的整合嗎？但它沒有。更何況，衛生部甚至沒有告訴公眾此平台與醫院系統的整合還沒有完成。如果計劃中沒有開發API此項工作，衛生部應告知公眾尚未完成與醫院系統的整合，因為衛生部有同意要進行整合。在未來，如果API的開發成為計劃的一部分，但一些醫院執行的整合工作沒有成功，衛生部也應該告訴大眾事情的進展。第二，沒有與醫院系統整合的系統遠非理想平台應有的樣子。如何達到理想狀態？達到理想狀態的條件除了工程師的能力以外，還有關於如果世界上沒有API這個東西，預算能否滿足與 496 個系統整合的要求，以及有限的時間是否足夠完成這樣的工作。在我看來，即使世界上沒有 API 這樣的東西，開發供應商必須自己進行 496 次整合，2億的預算應該包括與某些醫院系統的整合工作，但我不確定是否夠整合 496 個系統就是了 (雖然這麽說，這應該是有可能的 – 只是我不確定)。然而，預算不足也不應成為藉口。開發供應商或衛生福利部要麽提高與 496 個系統整合的預算，要麽減少預算 (使其低於 2 億) 以移除掉與其他平台整合的要求。沒有與醫院平台的整合，2億太貴了，因此還是浪費了。無論如何，世界上有API這種東西作為整合的解決方案，需要注意的是 2 億已足夠包含API的開發了。

7.(3).3 介面

疫苗接種平台的另一個問題是它的介面 (螢幕上看到的畫面)。

7.(3).3.1 介面並不 “使用者友善”

一位台灣人指出：“都已經上去登記意願了，還要在收到簡訊通知之後，再去另一個系統預約接種。 那怎麼不全部自動化就好了？登記了意願之後，平台就直接將用戶排入接種疫苗排隊裡面，疫苗到了，平台會自動通知用戶預約的時間和日期。這樣不是更方便嗎？^[38]https://www.dcard.tw/f/2019_ncov/p/236475248 ” 這個建議很有道理，我只會補充一件事：登記工作還應該包括用戶的有空日期和時間區段，這樣系統安排的預約時間就會對用戶來說更方便。不過，讓我們也看看為什麼政府想要有這樣的流程。根據《天下雜誌》，政府採取先登記後預約兩步驟流程的原因有兩點。第一點，疫苗到貨時間不一，先開放意願登記能確切掌握民眾偏好，在疫苗到貨量足夠涵蓋登記人數時，再通知已登記的人進行預約。第二點，意願登記順序並不影響接種的先後順序。如果以登記時間做為依據，將可能讓較懂得使用數位工具的人佔盡先機。所以，未來政府通知預約時，是依照「長幼有序」原則，以出生年來安排施打順序。 ^[39]https://www.cw.com.tw/article/5117434 。

避免不知道如何使用數位工具的老年人落後的擔憂是有道理的。華盛頓州遇到了類似的問題，並且將其流程改為與台灣相似的流程。由於太多人爭先恐後預約接種，預約接種是很困難的，在2021/3/10，華盛頓州政府開始改為預先登記的流程。依據每週分配到的疫苗量與民眾接種優先級別、居住區域及工作性質，個別通知預約^[40]https://www.cna.com.tw/news/firstnews/202103170290.aspx 。

然而，在我看來，疫苗平台仍然不應該有這樣的兩步驟流程。

第一，關於上述第一點: 政府希望等到庫存足夠涵蓋登記人數，

不，提議的流程仍然是可以讓政府等待直到特定類型疫苗的庫存足以涵蓋登記人數，因為該平台將用戶排在接種的隊伍中。請注意，平台應自動通知用戶預約時間為何時：只需讓平台等待並在庫存足以覆蓋註冊人數時再自動安排預約。疫苗的到達時間是不可預測的，平台如何知道疫苗何時到達呢？開發一些在平台後台的功能，讓政府人員能夠記錄 “[特定數量][特定類型]疫苗 在 [某日] 到達，並分發到[XXX]縣“。

第二，關於上述第二點: 政府希望接種的順序是“出生日期”，而不是“優先登記的順序”，因為擔心會使用數位工具的人可能會佔盡先機，不，這個解決方案有一個嚴重的問題。老年人被優先安排並通知預約後，實際預約時間不還是按照老年人們之間預約的先後順序嗎？只是是按照第二步的預約順序。是的，老年人確實被優先安排，我同意他們需要被優先安排，但有更好的解決方案，就是在登記疫苗種類偏好的第一步中優先考慮老年人。在第一步中添加年齡作為優先條件可以輕易地解決此問題。你看，無論哪種方式，都必須讓老年人使用科技，或者如果他們不知道如何上網預約，他們就去藥局預約。那麼，為什麼不通過添加年齡作為優先條件並刪除第二步來簡化流程呢？在我看來，由於設計這個系統的人和認同這個複雜流程的人都沒有考慮在第一步中添加條件，他們在事物的分類和排列以及邏輯思維上都有嚴重的問題。

華盛頓的情況也是如此。只需開發讓政府人員在後台記錄和分配可用疫苗數量的功能，添加工作性質和年齡等條件，並在第一步中優先安排某些職業或特定年齡的人，就足夠在防止混亂的同時安排接種。

7.(3).3.2 介面美觀度

台灣的疫苗接種平台的介面，比起我們經常使用的現代網站或App來說，並不美觀。 CVS Pharmacy 的美國平台做得更好。你可以從這篇文章中看到一些介面截圖。事實上，政府的許多數位工具的介面都很醜陋。這是2020年政府健保APP預約口罩的介面 (點擊連結)。直到2021年政府更新，所以現在我們才終於有了一個介面漂亮的APP。我只是在抱怨為什麼我們在2020年時有個介面很醜的APP。我們經常使用的許多APP的介面，例如Facebook，或者台灣的銀行在2020年之前已經有了非常現代和漂亮的介面。當我看到來自政府的健保App的介面，我以為我活在20年前，大多數網站都不關注介面美觀度的年代。當政府計劃將來開發任何其他網站或App時，一定要考慮介面美觀度。

雖然我說美國的平台做得更好，但這只是一個例子。 美國的一些平台其實也很醜陋。 紐約Vaccine Finder (找尋疫苗) 的介面是醜陋的介面示例之一 ^[41]https://vaccinefinder.nyc.gov 。 這些美國平台的介面看起來已經過時的原因可能是比爾蓋茲在他的書中所說的：州政府缺乏資金和資源。 不過，我所指出的台灣的平台，是來自中央政府，而不是地方政府，中央政府確實有足夠的錢做一個合適的網站或APP (2億)。 所以台灣政府在審查這些數位工具時有一個嚴重的問題，因為檢視這些數位工具甚至不需要一定程度的介面美感。我建議台灣政府多看看其他漂亮APP的介面。

閱讀第六部分

透過捐款和在社群媒體上關注我來幫助我

我撰寫的每篇文章在撰寫前都經過我數天的研究和思考。如果你喜歡我的文章，請不吝捐款支持我，這樣我可以撰寫更多有品質的文章。
注意: 捐款的單位是美元 – 美元兌新台幣約為 1:30 (1美元=30元台幣)

如果你喜歡我的文章，請分享此篇文章到你的社群媒體頁面，這樣我的文章就可以被更多人看見。
同時也請透過點擊下方連結來關注我的社群媒體(包含Facebook)，這樣你就可以收到我最新的文章。
關注我的社群媒體: 臉書Facebook | Twitter | Linkedin

文章禁止轉載