醫療保健AI治理框架：HIPAA、FDA SaMD和臨床監督要求

醫療保健中的AI不是理論性的治理挑戰。它是一個具有特定標準、審計期望和責任影響的監管合規要求。部署AI的醫療保健組織面臨分層監管環境：HIPAA 管理數據處理，FDA 監管符合醫療設備資格的軟件，EU AI Act 的高風險分類涵蓋了在歐洲業務中使用的臨床決策支持系統。

本框架涵蓋醫療保健AI部署所需的治理結構、監督機制和文件實踐。

監管全景：哪些適用於您的AI系統

在設計治理之前，確定哪些法規適用。

HIPAA 適用，如果您的AI系統處理、存儲或傳輸受保護的健康信息（PHI）。這包括以患者數據作為輸入（臨床記錄、影像元數據、實驗室值）的系統，或產生包含 PHI 輸出的系統。HIPAA 的安全、隱私和違規通知規則都延伸到接觸 PHI 的AI系統。

FDA 的醫療設備軟件（SaMD）框架適用，如果您的AI系統符合 21 USC 321(h) 下的醫療設備定義：旨在基於患者數據診斷、治療、緩解、處理或預防疾病，或影響身體結構或功能的軟件。提供患者特定建議的臨床決策支持軟件通常符合資格。行政AI（調度、賬單、沒有臨床建議的文件摘要）通常不符合。

EU AI Act 的高風險分類適用於在歐盟醫療設備法規覆蓋的醫療設備和臨床決策支持系統中使用的AI系統，在歐盟內部或向歐盟患者部署。高風險分類要求風險管理系統、數據治理文件、對部署者的透明度、人工監督能力和在歐盟數據庫中的登記。

聯合委員會和 CMS 標準越來越多地在認可和認證標準中處理AI，特別是臨床決策支持治理和臨床人員培訓要求。

在構建治理結構之前，確定哪些適用於您環境中的每個AI系統。合規負擔在這些框架中有很大不同。

臨床人機協作設計

對於為臨床決策提供信息的AI系統，人機協作架構不是可選的治理——它是設計基線。每個臨床AI部署必須回答三個結構性問題：

AI為哪些決策提供信息？ 精確定義決策範圍。「協助膿毒症風險分層」足夠具體，可以圍繞其設計治理。「協助臨床決策」太寬泛，在沒有清晰度的情況下創造責任。

誰在AI輸出影響患者護理之前審查它？ 識別負責審查的特定角色（主治醫師、護士、藥劑師）。審查者必須有臨床權力接受、修改或拒絕AI建議。如果唯一審查輸出的人是輸入數據的同一個人，這不是有意義的監督。

當AI和臨床醫生不同意時會發生什麼？ 覆蓋工作流程與默認工作流程同樣重要。記錄覆蓋機制，當不遵循AI建議時要求記錄臨床理由，並追蹤覆蓋模式作為質量信號。

置信度閾值和升級

設計良好的臨床AI系統不以相同方式呈現所有輸出。將置信度閾值構建到呈現層中：

高置信度輸出（模型在其驗證範圍內運行）：以清晰的推薦行動呈現給負責的臨床醫生
中等置信度輸出（模型在其驗證範圍的邊緣）：在行動之前標記以供明確的臨床醫生審查
低置信度輸出（超出分佈的輸入）：升級到高級臨床醫生或標記為僅人工評估，不要將AI建議呈現為指導

閾值校準應針對您的臨床群體進行驗證，而非僅針對基準數據集。分佈偏移是真實現象——在一家醫院群體上訓練的模型在另一家醫院的置信度特徵可能不同。

AI系統的 HIPAA 合規

AI系統的 HIPAA 合規有幾個標準數據處理框架不完全涵蓋的組件。

最低必要標準

HIPAA 的最低必要標準（45 CFR §164.514）要求將 PHI 訪問限制在完成預期目的所需的最低限度。對於AI，這意味著：

AI系統應只接收它實際需要執行其功能的數據元素。膿毒症預測模型不需要患者的保險信息或賬單代碼。設計數據管道只傳遞必要的字段。
AI系統本身的基於角色的訪問控制：賬單編碼員應該能夠查詢AI獲取編碼協助，但不應能夠查詢臨床AI獲取患者特定的臨床評估。
查詢級審計：每個包含 PHI 的AI查詢都必須記錄用戶的身份和允許查詢的角色授權。

審計控制要求

HIPAA 的審計控制標準（45 CFR §164.312(b)）要求記錄和審查包含 PHI 的系統中活動的機制。包含或處理 PHI 的AI系統必須產生包含以下內容的審計級別日誌：

查詢時的用戶身份和角色
UTC 時間戳
查詢中存在的數據元素（對於高容量系統不一定是完整查詢內容，但足以識別涉及哪些 PHI）
查詢的模型版本
交付的輸出
輸出是否用於臨床決策（如果您的系統捕獲此信息）

這些日誌必須按照您的 HIPAA 保留計劃保留，並且必須可在違規調查或 OCR 審計時生成。

業務夥伴協議

如果您的AI供應商代表您處理 PHI，HIPAA 要求業務夥伴協議（BAA）。這適用於：

接收包含 PHI 提示的雲端AI API 提供商
在包含 PHI 的數據集上訓練的微調平台
您的AI模型運行的推論托管提供商

如果您在 PHI 上微調並在本地部署，推論層不需要 BAA（您是您自己的業務夥伴）。如果訓練步驟涉及第三方計算提供商，則需要 BAA。

FDA SaMD 治理要求

如果您的AI系統符合醫療設備軟件資格，FDA 治理要求除 HIPAA 之外也適用。

預定變更控制計劃

FDA 的 AI/ML SaMD 指導強調預定變更控制計劃（PCCP）——記錄初始清算後如何管理模型更新、再訓練和性能變化。PCCP 應描述：

觸發模型審查的性能指標和閾值
評估模型變更是否構成需要新監管提交的修改的過程
在部署再訓練模型之前的臨床驗證要求
您將如何向臨床用戶傳達變更

對於您擁有的微調模型：您控制再訓練過程。記錄它。對於基於雲端 API 的系統：您的 PCCP 必須考慮供應商的模型更新實踐，這可能不在您的控制之下——這是許多 SaMD 開發者偏好自有模型基礎設施的原因之一。

算法透明度

FDA 關於基於 AI/ML 的 SaMD 的指導包括透明度要求。臨床用戶和臨床決策者必須能夠訪問：

AI在做什麼（其臨床功能）
它在什麼數據上訓練的（在類別層面）
其已知性能特徵（相關子組的準確率、靈敏度、特異度）
其已知限制（性能較低的患者群體，模型可能表現不佳的輸入條件）

這些信息應記錄在模型卡中，並讓使用該系統的臨床人員可訪問。

上市後監控

SaMD 需要上市後監控計劃。對於AI系統，這意味著追蹤：

模型性能對照真實世界臨床結果（不僅僅是保留數據上的預測 vs. 觀察）
AI可能對臨床錯誤有貢獻的不良事件報告
作為性能信號的覆蓋模式
用於偏差檢測的人口統計性能監控

醫療保健AI的審計跟蹤規格

醫療保健AI審計跟蹤必須捕獲足夠的信息以重建每個AI影響的臨床決策。每次查詢的最低記錄：

字段	值
事件 ID	每次查詢的唯一識別符
時間戳	UTC，毫秒精度
用戶 ID	連接到人力資源/資質認定系統
用戶角色	查詢時授權
患者 ID	按日誌政策去識別或假名化
包含的數據元素	類別（實驗室、生命體徵、記錄），日誌中無完整 PHI
模型 ID	特定模型版本和適配器版本
交付的輸出	呈現給臨床醫生的建議
臨床醫生行動	已接受 / 已修改 / 已拒絕（如果捕獲）
覆蓋原因	如果拒絕，自由文本（如果捕獲）

保留期：HIPAA 對覆蓋實體的最低要求是 6 年。州法律可能延長此期限。EU AI Act 高風險系統要求 10 年日誌保留。

治理委員會結構

醫療保健AI治理需要跨職能問責。最小可行治理委員會包括：

臨床倡導者：能夠評估AI建議的臨床有效性，並作為治理與使用系統的臨床人員之間的聯絡人的醫師或高級執業提供者。

合規官或隱私官：負責每個AI部署的 HIPAA 和監管合規審查。

信息安全：負責訪問控制、審計日誌完整性和AI基礎設施的數據安全。

法律顧問：審查 FDA 監管狀態、供應商合同（BAA、賠償）和責任影響。

IT/工程：負責基礎設施、模型部署和日誌實施。

此委員會至少應每季度開會一次，並在每次新的AI部署、模型更新或AI範圍的重大變更之前開會。

醫療保健AI的本地基礎設施

有嚴格 PHI 處理要求的醫療保健組織有結構性原因偏好本地AI推論。當AI模型在您的基礎設施上運行時：

PHI 永遠不會離開您的網絡到達雲端 API 端點
您現有的網絡訪問控制適用於AI系統
您的審計日誌基礎設施以與任何其他臨床系統查詢相同的方式捕獲AI查詢
對於每個生產查詢，您不依賴與第三方推論提供商的 BAA

部署模型：使用去識別化或合成訓練數據在雲端 GPU 上微調，導出到 GGUF 格式，通過 Ollama 或 llama.cpp 在您的臨床網絡上本地部署推論。雲端用於訓練，本地用於推論。

預約與 Ertas 的發現電話 →

Ertas Data Suite 完全在您的基礎設施上運行——操作期間沒有數據外流，沒有雲端推論調用，以及每個處理步驟的操作員身份日誌記錄。對於 PHI 處理不可商量的醫療保健組織，本地架構是使AI治理可行的基礎。