臨床決策支援中的人在迴路：醫療保健 AI 應該（和不應該）如何運作

2021 年，美國一家醫院系統部署了一個 AI 工具，用於預測患者惡化並標記高風險患者以便早期干預。該系統在整體上是準確的。但它沒有被設計為清楚地傳達哪些特定的生理指標驅動了每個標記，或者當五十名患者同時被標記時如何設置優先級。護理人員被警報淹沒，缺乏每個警報的上下文，開發了一些變通方法。高置信度標記被確認後降低了優先順序。患者情況惡化。AI 沒有缺陷。人在迴路的流程才是。

這是醫療保健 AI 中最重要的失敗模式。不是失控的模型。不是災難性的幻覺。而是嵌入在臨床工作流程中的技術功能系統，使有意義的人類監督在結構上不可能。

FDA 的 SaMD 框架及其要求

FDA 根據醫療設備軟體（SaMD）提供的信息的重要性及其影響的醫療情況狀態，將其分為三個風險等級。

I 類 SaMD：低風險。為非嚴重病症提供信息的 AI，其中不正確的信息不太可能造成患者傷害。例如：追蹤睡眠模式的健康應用程式。最低監管要求。

II 類 SaMD：中等風險。為非嚴重或嚴重病症的臨床管理提供信息，或驅動非嚴重病症的臨床管理的 AI。需要 510(k) 清關。必須證明與先前設備的實質等效性。HITL 是預期的；軟體應提供臨床醫生審查並採取行動的信息。

III 類 SaMD：高風險。診斷、治療或驅動嚴重或立即威脅生命的病症的臨床管理的 AI。需要上市前批准（PMA）。HITL 不是可選的。FDA 的立場是明確的：繞過合格臨床醫生審查的 AI 建議，對 III 類適應症不可批准。

FDA 2019 年及更新的 2023 年關於預定變更控制計劃（PCCP）的指導增加了第二個維度：模型更新。PCCP 預先定義製造商可以對基於 AI/ML 的 SaMD 進行哪些類型的更改，而不需要新的提交。每個 PCCP 必須包括製造商將如何驗證更改按預期執行的描述——且該驗證必須涉及在更新模型部署到生產之前對臨床性能資料的合格人工審查。你不能像更新 Web 應用程式一樣靜默更新臨床 AI 模型。

HIPAA 的問責問題

HIPAA 不直接解決 AI 問題。它不需要。它建立的問責結構使要求變得清晰。

覆蓋實體——醫院、診所、健康計劃、醫療保健資訊交換中心——對其員工和業務合作夥伴在處理受保護健康信息和做出治療決定方面的行為負法律責任。主治臨床醫生對在護理過程中做出的臨床決定負責。

AI 系統不能是覆蓋實體。它在臨床決策意義上不能是業務合作夥伴。它沒有可撤銷的許可證，也沒有可耗盡的醫療事故保險。當 AI 系統做出臨床建議而臨床醫生在沒有獨立專業判斷的情況下採取行動時，責任風險不會轉移給 AI 供應商。它留在臨床醫生和機構身上。

這意味著任何繞過醫生審查的臨床 AI 部署——允許 AI 輸出直接驅動治療而沒有記錄的臨床驗證——都會造成 HIPAA 問責缺口。機構不能說是 AI 決定的。他們部署了 AI。他們擁有這個決定。

HITL 在臨床實踐中的樣子

醫療保健中的良好 HITL 不是單一模式。它因臨床上下文和風險層級而異。

影像 AI（放射學、病理學、皮膚科）：AI 分析圖像並產生結構化輸出——標記區域、鑑別診斷、置信度分數。放射科醫生或病理科醫生將此輸出作為額外信息接收，而非最終診斷。他們進行自己的獨立分析，然後與 AI 的發現進行比較。他們簽名的報告是臨床記錄。AI 的輸出是他們使用的工具，而非判斷。

藥物決策支援：藥房 AI 標記潛在的藥物相互作用或劑量異常。系統以具體性呈現標記：相互作用的藥劑、關注機制、嚴重程度層級和已發表的參考文獻。藥劑師審查，要麼確認這個患者臨床上下文的訂單是合適的，修改訂單，或升級到開具處方的醫生。藥劑師的名字在驗證上。

預先授權 AI：保險和醫療系統 AI 工具根據臨床文件預先填充預授權請求。臨床人員審查預填充的請求，確認它準確反映了患者的記錄，並在其專業證明下提交。

敗血症預測：AI 標記超過風險閾值的患者。護士或臨床協調員審查被標記的患者，對哪些在當前情況下代表可操作風險應用臨床判斷，並確定升級到快速響應團隊的人員。標記不是行動。臨床醫生的評估才是。

警報疲勞問題

警報疲勞是設計良好的 HITL 走向消亡的地方。

一個在每班為管理 12 張床位的護士標記 50 名患者的臨床 AI，並不是在提供決策支援。它在提供噪音。當臨床醫生被警報淹沒——大多數在檢查時，對其特定患者上下文信號弱或不相關——他們會適應。他們在不閱讀的情況下確認警報。他們制定一攬子政策：「如果只是 AI 標記，記錄到病歷中然後繼續。」人在迴路的流程在技術上就位。它在功能上是惰性的。

關於這個問題的研究是清楚的。2023 年 JAMIA 的一項研究發現，在一個 EHR 部署中，臨床醫生覆蓋了超過 90% 的 AI 生成藥物警報。不是因為 AI 總是錯的——它有 40% 的時間是對的。但信噪比太低，辨別哪 40% 需要工作流程不支持的努力。

警報疲勞不意味著臨床醫生停止關心。它意味著系統是為覆蓋範圍設計的，而非為臨床可用性設計。

結果是高信號警報在低信號警報的噪音中被遺漏。AI 在那裡。人類在那裡。迴路還是斷了。

設計臨床醫生實際使用的 HITL

警報疲勞的解決方案不是為了減少警報而減少警報。而是具有足夠信號品質的警報，讓審查員可以快速做出確信的決定。

原則 1：閾值校準優於一攬子警報。 如果你的敗血症模型對每個預測風險超過 15% 的患者發出警報，你將為正在被適當管理且床邊護士已知不在惡化的患者生成警報。將閾值調整到警報改變臨床行為的地方——而非模型在技術上正確的地方。

原則 2：顯示原因，而非只是結果。 「患者因敗血症風險被標記」不是 HITL。「患者因敗血症風險被標記：體溫 38.9°C，乳酸 2.1 mmol/L 在 4 小時內趨勢上升，MAP 下降——四個 SIRS 標準中滿足三個」才是 HITL。審查員需要足夠的信息來獨立驗證 AI 的推理，而非出於信任接受它。

原則 3：與風險成比例的阻力。 對於輕微、眾所周知的相互作用的藥物相互作用警報，應該只需一次點擊即可確認。對於臨床醫生兩小時內未見的患者的高置信度敗血症標記，應該需要記錄的臨床評估。解除的努力應與出錯的成本相匹配。

原則 4：測量審查員行為，而非只是警報量。 如果 95% 的警報在五秒內被解除，你沒有審查流程。按警報類型追蹤決策時間、覆蓋率，以及被覆蓋與被確認警報的下游結果。這些資料告訴你你的 HITL 是否在運作。

Ertas Data Suite 如何支持醫療保健 AI 開發

在臨床 AI 系統接觸患者之前，訓練資料必須準備好。在醫療保健中，這意味著使用 PHI——而 PHI 不能離開建築物去坐在雲端供應商的訓練基礎設施中。

Ertas Data Suite 完全在本地作為本地桌面應用程式運行。PHI 編輯、標注和匯出都在機構的安全邊界內發生。每個標注都記錄了操作員身份和時間戳。稽核追蹤內建在工具中，而非事後從系統日誌中組裝。

對於建立或微調用於臨床應用的 AI 的醫療保健組織，資料準備管道需要滿足與部署模型相同的 HITL 和治理標準。在隱私合規、可稽核管道中準備的資料上訓練的臨床 AI，從可辯護的基礎開始。

有關更廣泛的 HITL 框架，請參閱什麼是人在迴路 AI？。有關為醫療保健部署微調模型的內容，請參閱我們關於為臨床部署微調醫療保健 AI 的文章。

預約與 Ertas 的探索通話 →

保持人類在迴路中的臨床 AI，不是等待被取代的 AI。它是通過可稽核、可解釋和臨床醫生控制來贏得信任的 AI。FDA、HIPAA 和臨床倫理都指向同一方向。你機構的問題是你目前的 AI 部署是否被設計為滿足這個標準——或者只是設計為看起來像是這樣。