一個人也能打造的智慧醫院

「The menu is omakase.」出自 DHH 寫的 The Rails Doctrine。

第一次認真讀到 Rails Doctrine 裡這條原則時，我正在為醫院寫一支又一支的系統。當時我沒想到，這個從壽司店借來的字，後來會長成我對智慧醫院的整套想法。

Omakase，日文「お任せ」，把選擇交給主廚。你不必從上百種食材裡自己配一桌，你信任一組經過設計、有主張的搭配。Rails 把這個態度帶進了 web 開發，一套整合好的預設組合，讓一個人也能做出一個完整的產品。

我想做的，是把同樣的態度帶進醫院。我把它叫做 Omakase Smart Hospital。

智慧醫院的瓶頸，不在技術

先講一個我觀察很久的現象。

過去要在醫院蓋一套系統，幾乎只有一種想像：大系統、大廠、大預算、長專案。每一個環節都要客製，每一份資料都鎖在自己的系統裡，換一個模組往往要動整台機器。

這條路不是錯的，很多大型醫學中心也只能這樣走。但我慢慢發現，真正卡住智慧醫院的，常常不是技術不夠先進，而是我們預設它「必須很大」。大，才顯得專業；大，才敢採購。於是很多小而好的想法，還沒開始就被規模嚇退了。

我想問的是另一個問題：如果它不必那麼大呢？

這幾年，我持續用開源的工具鏈親手做醫療系統。用 Ruby on Rails 當地基，用 FHIR 當資料的共同語言，用 LINE 接住病人，用 Kamal 把系統部署出去。

最讓我意外的是成本。當這些成熟的開源技術兜在一起，一套能實際運作的服務，一個月的部署開銷可以壓到幾塊美金。不是因為便宜行事，而是工具鏈真的進步到了這個程度。

一個人能扛起的範圍，比我們以為的大得多。Omakase Smart Hospital，就是我把這幾年動手做的心得，整理成的一套主張。

開放標準是地基。 智慧醫院要蓋在 FHIR、REST API、event-driven 這些開放標準上。醫療資料不該被單一系統鎖住，能流動的資料才有價值。

架構要像 LEGO，不是像巨石。 一套好的醫院系統，應該由可以獨立開發、升級、替換的模組組成：Core HIS、FHIR Server、事件匯流排、AI 服務、病人端 App。哪一塊要換，就換哪一塊，不必動整台機器。

開源優先。 醫療 IT 長期被封閉系統主導，但 Rails、PostgreSQL、Kafka、Linux、container 這些開源技術，讓小團隊也能蓋出大平台。這正是「一個人也扛得動」的底氣。

AI 要長在系統裡，不是掛在旁邊。 AI 分診、AI 病歷助手、AI 臨床決策輔助、AI 病人問答，這些不該是外接的玩具，而該直接整合進醫療資訊系統的血管裡。

系統終究是為人服務的。 醫師、護理師、行政、病人，系統要幫他們減負擔，而不是多一份工。我也相信寫系統的人要快樂，Developer happiness 和使用者體驗，一樣重要。

我知道「一個人的智慧醫院」聽起來像逞強。所以我要說清楚，這不是叫每間醫院都裁掉團隊，也不是說大系統沒有價值。

我想證明的是另一件事：當一個人就能做出能跑、醫院願意用的東西，智慧醫療的試錯成本就被打到很低。 低到你可以先做一個 prototype 驗證想法，而不是先寫三個月的規格書；低到失敗也不心疼，可以快速再試一次。

這種「小團隊也能蓋大系統」的工作方式，是 Omakase 的工程精神：快速原型、迭代設計、平台思維。工程師不只是在寫程式，是在設計醫療的未來長什麼樣子。

這套想法對台灣特別有意義。

台灣正在推 FHIR、推電子病歷交換、推醫療資料互通，政策的風向是對的。但真正把國際標準，接到本地醫院的老系統、接到健保的現實裡，中間需要有人動手，而這件事的中文經驗幾乎是空白的。

我打算持續把我做的、我踩的坑、我想的，一篇一篇寫下來。不是因為我做得多完美，而是因為這條路太少人走，而我剛好站在能走的位置上。

Omakase Smart Hospital 不是一個產品，是一種相信。相信醫療系統可以更開放、更模組、更以人為本，也相信這樣的系統，不必大到一個人扛不起。

如果你也在醫療或技術的某個位置上，對這件事有一樣的相信，歡迎一起。