大多數醫療 AI 的方向
2026 年，任何一家醫療 AI 供應商的 demo 流程大致相同：醫師對著麥克風說話，AI 轉譯、結構化成 SOAP（Subjective／Objective／Assessment／Plan，病歷四段式：主觀／客觀／評估／計畫），AI 草擬醫囑、帳單碼、出院摘要，AI 寫進 EHR（Electronic Health Record，電子病歷）。醫師離開去吃飯。
這個流程的價值訴求是效率。背後的假設是：只要模型「夠準」，醫師就可以脫離 loop。
iRehab Doctor AI 技術上做得到每一個步驟。我們選擇不這樣接。
這篇文章解釋為什麼。
Draft-Only Enforcement
iRehab Doctor AI 圍繞一條強制規則而建構，我們稱之為 Draft-Only Enforcement（草稿限定原則）：
任何由 AI 產出的醫療文書都標記為 draft。除非具執照的醫師手動按下確認，draft 永遠不會進入病人的 official record。
實際意義：
- AI 可以產生評估、處方、手術記錄、帳單——但不能送出。
- AI 可以填欄位、整理上下文、提供最佳起點——但不會自己寫進 EHR。
- 文書不能一步存檔。Draft → Confirm 是兩個動作，不能合併。
技術上這是一條微不足道的限制。困難不在工程，而在每一個產品直覺都想把第二步拿掉的時候，我們能不能堅持留著。
「整合」可能指的三種事
醫師要求「文書整合」時，通常是三種意思中的一種。這三種想像都合理——但走到底可能會指向同一個我們想避開的預設。
整合 = 自動化
常聽到的想法是：「全部幫我寫，我完全不碰。」最後那份文件上掛著醫師的名字，醫師卻沒讀過。責任鏈名義上完整，實際上已斷。在醫療系統裡，那個缺口就是病患風險藏身之處。
整合 = 單一表單
另一種想法是：「把所有欄位放在一個畫面，我不必切 tab。」Cerner 和 Epic 做了 30 年。欄位數增加，打字時間沒下降。真正的挑戰——每一次看診的認知負荷——不是 UI（User Interface，使用者介面）排版能解決的。
整合 = AI 寫完 = 完成
最深的一層想像，是把「AI 寫完」等同於「問題解決」。醫療文書不是交付物，是一次臨床判斷的證據記錄。「medial meniscal tear post-repair，考慮 MRI follow-up」這句話的價值，在於一位具名醫師把自己的執照放進去了。如果 AI 寫、醫師沒讀就簽，這段紀錄剩下的只有字句，沒有證據重量。
我們選擇蓋的東西
iRehab 採取了相反的方向。我們不整合表單，我們整合上下文。
醫師打開 Doctor PWA（Progressive Web App，漸進式網頁應用）看到的不是 37 個欄位的模板，而是一段臨床脈絡摘要（POD＝Post-Operative Day 術後第 N 天；VAS＝Visual Analog Scale 疼痛量表 0-10）：
POD 14。VAS 6 → 3。家屬 3 天前拍的傷口照——輕微紅腫。昨天完成 70% 的運動處方。
[ AI 建議 SOAP 草稿 ]
醫師讀 draft、改兩個字、按確認。整合完成。
目的不是把十份表單合成一份。是在五秒內，把最好的起點交到臨床醫師手上，然後退開。
為什麼第二步不能拿掉
醫療 AI 產業會持續有壓力要把確認步驟刪掉。每一季模型會更準、準確率會更好看，會有人主張人工檢查已經多餘。這個壓力我們預期會來，我們會繼續把第二步留著。
因為當 Draft → Confirm 被合併成單一動作的那一刻，臨床責任鏈不是被弱化，是被切斷。而臨床系統的韌性，完全活在那條鏈的完整性裡。
這條規則背後還有一層原則。如果有一天 AI 能完全取代醫師寫病歷、開處方、動手術——那就不只是技術的進展，還意味著「醫師」這個受執照、受問責的職業本身正在被重新定義。我們不認為技術已經到了那一步。我們也希望，那一天不要太快到來。
把原則往上游推
Draft-Only Enforcement 本來是為了保護醫師。它正在變成對病患也成立的保護。
病患還沒進診間，iRehab 就能根據最近的症狀回報，預先草擬 SOAP 裡的 S 欄。家屬協助填寫時，AI 草擬，醫師一樣要確認。而當病患真的進診間坐下，他有權改寫任何一個為他草擬的字。
責任鏈不是只保護醫師。它保護系統裡的每一個關節。
結語
Draft-Only Enforcement 不是技術妥協的折衷。這是我們選擇和多數臨床 AI 走不同路徑的原因。
AI 起草。人類確認。第二步不是摩擦，是第一步得以安全的原因。