案例拆解:一家醫院把病歷 AI 推上臨床端的過程——採用率、醫師工時與資安如何過關

早上七點四十,某區域教學醫院的內科晨會還沒散,一位主治醫師已經在病房外的推車前站了快十分鐘。他不是在看病人,是在補前一天的出院病摘。這種畫面,我們進場的第一週看了無數次。

醫院兩年前就上了一套號稱能自動生成病歷的 AI,採購流程漂亮、Demo 那天科主任們也點頭。但我們接手盤點時,實際打開系統看使用日誌:全院願意固定用它寫病摘的醫師,不到三成,而且集中在幾位年輕住院醫師身上。主治那一層,幾乎沒人碰。

問題不在模型。問題在沒有人把它「推上臨床端」——這正是我們這篇醫院 AI 導入案例想拆解的核心:一套技術上可行的病歷 AI,是怎麼從 4% 的邊緣工具,變成醫師願意天天用的東西。

先看數字,再談方法

我們習慣把採用率和工時放在最前面,因為醫院裡任何一句「這對臨床有幫助」都需要證據撐住。這是我們與該院合作十週後,一個內科病房 14 位醫師的實測對照:

我要誠實標一件事:草稿仍有 19% 需要醫師大幅改寫。我們沒有把這個數字藏起來,反而把它變成每週校準的燃料。AI 生成的病摘不是拿來直接送出的,是拿來讓醫師從「面對空白頁」變成「審一份初稿」。省下來的不是簽名那一秒,是前面組織思緒、翻檢驗結果、複製貼上的那二十分鐘。

FDE 進場:工程師坐進醫師辦公室

這個案子真正的轉折,是我們沒有把它當成一次軟體交付,而是派工程師進駐。

前四週,我們的 FDE 幾乎天天待在內科醫師辦公室,不是收需求文件,是看醫師實際怎麼寫病摘、卡在哪。我們很快發現,舊系統失敗的關鍵細節:它生成的病摘用詞是「一般台灣醫院」的平均值,但這家醫院的內科有自己一套慣用的診斷書寫格式,連科內對「病程摘要」該放多少檢驗數據都有默契。通用模型每次都寫得四平八穩、卻每次都不對味,醫師改到第三份就放棄,回去手打。

於是我們做的第一件事不是換模型,是把該院近三年、去識別化後的合格病摘餵進 RAG 知識庫,讓 AI 學會「這家醫院的醫師怎麼寫」。第二件事,是把生成入口直接嵌進他們原本的 HIS 病歷畫面裡——不是另開一個網頁、不是再登入一次。醫師點開病歷,草稿已經在那。

採用率會從三成爬到近八成,靠的不是說服,是把摩擦一格一格拿掉。我們每週固定和三位「意見領袖」主治坐下來看被改最多的十份草稿,隔週就把修正餵回系統。到第六週,連原本最抗拒的資深主治都開始主動提要求了。這是我們判斷一套系統「活了」的訊號:使用者開始把它當自己的工具,而不是被推銷的產品。

資安與院內流程怎麼過關

醫院導入 AI,最容易在資安這關卡死,而且往往卡在流程,不是技術。

我們一開始就把底線設死:所有病歷資料不出院。整套推論部署在院內的地端環境,病人的 PHI(受保護健康資訊)不經過任何外部 API。給模型的每一筆脈絡,都先過一層去識別化,把姓名、病歷號、身分證字號等欄位在進入 RAG 之前就遮罩掉。這一步不是為了合規表格好看,是為了讓資安室願意簽字。

流程面,我們沒有繞過醫院既有的治理機制,而是主動走完:資安風險評估、個資影響評估、以及送 IRB 審查臨床使用範圍。我們踩過的雷是——最初低估了跨部門溝通的時間,資訊室、資安室、醫品部、臨床端各有各的擔憂,光是「AI 生成的病摘出錯了誰負責」這個問題,就開了三次會。最後的共識很簡單也很關鍵:AI 只產草稿,醫師是唯一簽署者與責任者,系統全程留下誰在什麼時間改了什麼的稽核軌跡。這條界線一畫清楚,推進速度立刻不一樣。

回頭看,這個案子和我們做過的每一個都印證同一件事:醫院 AI 導入案例的成敗,八成不在模型選型,在有沒有人真的坐進現場,把採用率、工時與資安三件事一起扛到上線。

Demo 很美不算數。是那位主治醫師晨會後不再站在推車前補病摘,才算數。在 Tenten,我們做的就是把工程師嵌進客戶的臨床現場,陪到系統真的有人在用的那一天。