醫療 AI 微調：臨床部署的端到端流程

在醫療領域部署 AI 的挑戰不是技術上的——是流程上的。模型本身並不困難。困難的是資料治理、合規驗證以及在不讓資料離開機構的情況下讓一切運作起來。

本指南涵蓋從原始臨床資料到生產推理的端到端流程，重點關注實際實施問題，而不是理論。

流程概覽

醫療 AI 部署流程包含五個階段，每個階段都有特定的合規要求：

1. 資料識別和 de-identification
2. 資料集準備和格式化
3. 模型微調
4. 合規驗證
5. 本地部署和整合

不走捷徑。省略或草率處理任何階段都會在後面造成問題——無論是在審計中，還是在模型表現不如預期時。

第一階段：De-identification

在任何資料離開你的 EHR 或進入訓練流程之前，必須先進行 de-identification。

Safe Harbor 方法

HIPAA Safe Harbor 要求移除 18 類指定標識符：

1. 姓名
2. 地理細分（郵遞區號除外前三位數）
3. 所有日期（年份除外）
4. 電話號碼
5. 傳真號碼
6. 電子郵件地址
7. 社會安全號碼
8. 病歷號碼
9. 健康計劃受益人號碼
10. 帳號
11. 憑證/執照號碼
12. 車輛識別碼和序號
13. 設備識別碼和序號
14. 網址
15. IP 地址
16. 生物識別標識符（指紋、聲紋）
17. 全臉照片及可比較圖像
18. 任何其他唯一識別號碼、特徵或代碼

實際建議： 不要手動執行此操作。使用 Microsoft Presidio、Philter 或商業 PHI 移除工具等工具——它們使用 NER 模型進行自動識別，比手動審查更可靠。始終進行人工抽樣審查以驗證工具的準確性。

De-identification 流程

原始 EHR 資料
    ↓
PHI 識別（Presidio / Philter / 商業工具）
    ↓
自動移除/替換 18 類標識符
    ↓
人工抽樣審查（至少 5% 的記錄）
    ↓
De-identified 資料集記錄（審計追蹤）
    ↓
訓練流程

記錄你使用的工具、版本、驗證步驟，以及進行驗證的人員。這個文件在審計中至關重要。

第二階段：資料集準備

臨床筆記摘要

格式：

{
  "messages": [
    {
      "role": "user",
      "content": "摘要以下出院摘要的關鍵發現：\n\n[de-identified 出院摘要文字]"
    },
    {
      "role": "assistant",
      "content": "關鍵發現：\n- 主要診斷：[病況]\n- 住院時間：[N] 天\n- 關鍵干預措施：[程序]\n- 出院時的藥物更改：[列表]\n- 後續護理：[指示]"
    }
  ]
}

資料量： 每個摘要類型（出院摘要、進度記錄、手術記錄）需要 500-2,000 個範例。品質比數量更重要——300 個高品質摘要優於 2,000 個不一致的摘要。

醫療編碼（ICD-10/CPT）

格式：

{
  "messages": [
    {
      "role": "user",
      "content": "根據以下臨床文件，建議適當的 ICD-10 診斷代碼：\n\n[de-identified 臨床文件]"
    },
    {
      "role": "assistant",
      "content": "主要診斷：E11.65（2 型糖尿病伴有高血糖）\n次要診斷：I10（原發性高血壓）\nI25.10（動脈粥樣硬化性心臟病，自體血管）\n\n編碼理由：[說明]"
    }
  ]
}

患者信件生成

格式：

{
  "messages": [
    {
      "role": "user",
      "content": "為以下情況起草一封患者信件：[就診摘要、指示、後續護理]。使用適合 8 年級閱讀水平的語言。"
    },
    {
      "role": "assistant",
      "content": "[信件草稿，語言清晰，避免醫學術語]"
    }
  ]
}

第三階段：模型微調

LoRA 配置

臨床筆記摘要使用更高的 rank 和更長的序列，因為輸入文件通常較長且需要跨越更長距離捕捉關係。

使用 Ertas Studio 訓練

1. 將 JSONL 訓練資料上傳到 Ertas
2. 選擇基礎模型（見下方模型選擇部分）
3. 配置 LoRA 參數
4. 監控訓練損失——應該在前兩個 epoch 穩步下降，然後趨於平緩
5. 下載微調模型或 LoRA 適配器

模型選擇

第四階段：合規驗證

在部署之前，驗證：

資料合規：

• De-identification 日誌顯示所有 18 類 PHI 已移除
• 人工驗證覆蓋至少 5% 的訓練資料
• 訓練資料授權記錄在案（患者同意或 de-identification 豁免）
• 資料處理協議（DPA）覆蓋任何雲端訓練

模型性能：

• 在保留評估集上評估（最少 100 個範例）
• 記錄任務特定的準確率指標
• 臨床人員審查了 50 個以上的輸出範例
• 已識別並記錄邊緣案例和失敗模式

部署合規：

• 推理環境在 HIPAA 邊界內
• API 端點通過 TLS 1.2 以上加密
• 存取控制和審計日誌已到位
• 事件回應程序已更新以包含 AI 系統

第五階段：本地部署

最低配置（開發/小型生產）

• RTX 5090（24 GB VRAM）或同等配置
• 64 GB 系統 RAM
• 通過 Ollama 運行的微調模型
• 通過 REST API 與 EHR 整合

適用於：臨床工作流程自動化，非關鍵路徑輔助工具

生產配置

• A100 80GB 或 H100 GPU（單卡或多卡）
• 256 GB 以上系統 RAM
• 通過 vLLM 運行（更高吞吐量，連接更多並發臨床用戶）
• 負載均衡，高可用性設置
• 備份推理節點

適用於：高流量臨床工作流程，多個並發用戶

EHR 整合

大多數現代 EHR 系統（Epic、Cerner/Oracle Health）通過 FHIR API 暴露資料。整合模式：

EHR FHIR API → 提取臨床筆記 → 中間層 → 微調模型 → 輸出返回 EHR

中間層處理：

• 認證和授權
• PHI 的額外 de-identification（如果模型用於訓練/反饋循環）
• 審計日誌
• 速率限制和錯誤處理

代理商交付時間表

對於為醫療客戶實施此功能的代理商：

第一階段（第 1-2 週）：發現和規劃

• 確定目標使用案例和成功指標
• 評估現有資料可用性
• 確認 HIPAA 合規架構
• 確定利益相關者和審批流程

第二階段（第 2-4 週）：資料準備

• 實施 de-identification 流程
• 構建訓練資料集
• 臨床人員驗證訓練範例

第三階段（第 3-5 週）：微調和評估

• 在 Ertas 上訓練模型
• 評估保留集上的性能
• 臨床人員審查輸出品質

第四階段（第 4-6 週）：部署和整合

• 配置本地推理基礎設施
• 整合 EHR 系統
• 端到端測試

第五階段（持續）：監控和維護

• 追蹤準確率指標
• 收集臨床醫生反饋
• 定期重新訓練（每季度或當準確率下降時）

總時間表：4-6 週到初始生產部署，加上持續維護。

---