n8n + 本地 LLMs：構建符合 HIPAA 的自動化工作流程

醫療保健自動化有一個不可談判的要求：受保護的健康信息（PHI）必須保持私密。這就是為什麼將 AI 驅動的自動化引入醫療保健工作流程對許多組織來說感覺風險巨大——當你的 AI 提供者要求資料離開你的網絡時，合規負責人通常會介入並喊停。

本地端 LLMs 加 n8n 消除了這個緊張關係。在本地運行的 AI 模型讓 PHI 留在你的基礎設施中。n8n 的視覺化工作流程構建器使這些工作流程對技術和非技術團隊成員都透明可稽核。

本文逐步介紹三個實際醫療保健自動化，包括架構決策和 HIPAA 合規考量。

HIPAA 合規基礎

在深入具體工作流程之前，讓我們清楚了解技術保障措施：

什麼讓 LLM 整合符合 HIPAA：

• PHI 從不離開你的受控基礎設施
• 所有訪問都有完整的稽核追蹤
• 靜態和傳輸中的加密
• 基於角色的訪問控制，最小特權原則
• 記錄的 AI 使用政策和人工覆蓋要求

什麼使典型的雲端 AI 整合存在問題：

• PHI 通過 API 呼叫發送到第三方服務器
• 即使有 BAA，資料也在你的控制之外流動
• 缺乏如何訓練或日誌提示的可見性

本地 LLM 部署（使用 Ollama 或 vLLM 等工具）加 n8n 托管在你的基礎設施上，意味著 PHI 永遠不會離開受控環境。

架構概覽

典型的符合 HIPAA 的 n8n + 本地 LLM 堆疊：

EHR 系統
    ↓ HL7/FHIR webhook
n8n（在你的基礎設施上）
    ↓ HTTP 請求（本地）
Ollama / vLLM（在同一網絡上）
    ↓ 帶有 LoRA 適配器的本地 LLM
n8n 後處理
    ↓ 安全的內部 API
EHR 系統（結果）

所有元件都在你的網絡邊界內運行。沒有外部 API 呼叫。稽核日誌記錄每個步驟。

工作流程 1：臨床記錄摘要

問題： 醫師花費數小時記錄每次就診後的詳細記錄。AI 可以草擬初始摘要，讓醫師審閱而不是從頭開始。

工作流程觸發器： 醫師在 EHR 中標記記錄為「待摘要」

n8n 工作流程步驟：

1. Webhook 節點 — 接收來自 EHR 系統的觸發，其中包含記錄 ID（不是原始 PHI）
2. EHR API 節點 — 使用記錄 ID 從你的內部 EHR API 提取記錄（透過私有 VPN 上的 mTLS）
3. PHI 審查節點 — 自訂代碼節點，在發送到 LLM 之前確認你是在你控制的基礎設施內
4. HTTP 請求節點 — 帶有記錄文字的 POST 請求到本地 Ollama 端點（http://localhost:11434/api/generate）
5. 格式化節點 — 清理 LLM 輸出，確保 SOAP 格式（主觀、客觀、評估、計畫）
6. 草稿儲存節點 — 將摘要草稿寫回 EHR，標記為「AI 草稿——待醫師審閱」
7. 通知節點 — 在醫師工作站或電子病歷收件箱中提醒醫師審閱草稿

在 Ollama 節點的提示模板：

你是協助臨床文件記錄的 AI 助手。將以下臨床記錄摘要為 SOAP 格式。

記錄：
{{$node["EHR API"].json.note_text}}

提供結構化的 SOAP 摘要。保持臨床精確性。
不要添加記錄中不存在的任何信息。

HIPAA 注意事項：

• Ollama 在本地運行——PHI 從不離開你的網絡
• n8n 稽核日誌記錄每個節點執行及時間戳記
• 草稿標記為 AI 生成——需要醫師批准
• 不儲存原始提示日誌（僅記錄處理元資料）

工作流程 2：預約分診

問題： 前台工作人員手動路由傳入的預約請求，通常依賴不完整的患者信息。AI 可以分析請求並建議適當的護理水平。

工作流程觸發器： 通過患者門戶或電話後提交的新預約請求

n8n 工作流程步驟：

1. 表單 Webhook — 從患者門戶接收非結構化預約請求
2. 患者資料節點 — 從 EHR 獲取患者病史（內部 API 呼叫）
3. LLM 分診節點 — 本地 LLM 分析症狀描述和相關病史
4. 規則驗證節點 — 代碼節點，根據已批准的臨床協議驗證 LLM 建議
5. 緊急路由節點 — 如果 LLM 標記緊急症狀，立即升級到安全電話通知
6. 預約安排節點 — 對於常規分診，為患者建立具有適當提供者類型的預約建議
7. 工作人員審閱節點 — 前台工作人員在最終確認預約之前審閱所有 AI 分診

分診提示：

分析以下預約請求並建議適當的護理水平。

患者請求：{{$node["Form Webhook"].json.request_text}}
相關病史：{{$node["Patient Data"].json.relevant_history}}

將護理水平分類為：URGENT（24小時）、ROUTINE（1-2週）、PREVENTIVE（彈性安排）。
提供你建議的簡短理由。
不要做出診斷——僅基於描述的症狀優先考慮預約時機。

工作流程保障措施：

• 所有 AI 分診建議在最終確認前需要人工確認
• 緊急標誌不可被 AI 邏輯覆蓋——自動升級
• LLM 明確被指示不做出診斷，僅優先排序

工作流程 3：預先授權敘述

問題： 為程序提交預先授權需要整合多個資料來源的書面敘述——這對醫師來說是耗時且令人沮喪的工作。

工作流程觸發器： 在 EHR 中啟動的預先授權請求

n8n 工作流程步驟：

1. 預先授權 Webhook — 從 EHR 接收 PA 請求，包含程序代碼
2. 臨床資料聚合器 — 從 EHR 收集相關文件（診斷、先前治療、失敗治療）
3. 保險規則查詢 — 從內部保險規則資料庫（非 PHI）獲取保險公司特定要求
4. LLM 敘述生成器 — 本地 LLM 起草符合保險公司格式要求的 PA 敘述
5. 合規驗證器 — 代碼節點確認敘述包含必需的元素（診斷代碼、先前授權、醫學必要性理由）
6. 醫師審閱隊列 — 草稿敘述進入醫師審閱工作站
7. 提交節點 — 醫師批准後，敘述提交給保險公司（通過你的現有提交工作流程）

敘述生成提示：

起草用於程序預先授權的醫療敘述。

程序：{{$node["PA Webhook"].json.procedure_code}} - {{$node["PA Webhook"].json.procedure_name}}
診斷：{{$node["Clinical Data"].json.diagnoses}}
先前治療：{{$node["Clinical Data"].json.prior_treatments}}
失敗治療：{{$node["Clinical Data"].json.failed_treatments}}
保險公司要求：{{$node["Insurance Rules"].json.requirements}}

起草一個包含：醫學必要性、支持診斷、先前治療的文件、為什麼請求的程序是合適的下一步的敘述。
格式應專業且面向保險審閱。

HIPAA 稽核追蹤設置

符合 HIPAA 的部署需要完整的稽核追蹤。在 n8n 中：

在 n8n 設置中啟用執行日誌：

# n8n docker-compose 環境變量
N8N_LOG_LEVEL: info
N8N_LOG_OUTPUT: console,file
N8N_LOG_FILE_LOCATION: /data/logs/n8n.log
EXECUTIONS_DATA_SAVE_ON_SUCCESS: all
EXECUTIONS_DATA_SAVE_ON_ERROR: all
EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS: true

在每個工作流程中添加稽核節點：

在工作流程中的關鍵節點後添加一個代碼節點，將元資料記錄到你的 SIEM：

// 稽核日誌代碼節點
const auditEntry = {
  timestamp: new Date().toISOString(),
  workflow_id: $workflow.id,
  workflow_name: $workflow.name,
  execution_id: $execution.id,
  node_name: "Clinical Note Summary",
  action: "ai_processing_completed",
  patient_id: $node["EHR API"].json.patient_id,  // 不記錄原始 PHI
  processing_duration_ms: Date.now() - $execution.startedAt,
  model_used: "llama3.1-clinical-notes-adapter",
  output_requires_review: true
};

// 發送到你的 SIEM（內部端點）
await $http.request({
  method: 'POST',
  url: 'http://internal-siem:9200/hipaa-audit/_doc',
  body: JSON.stringify(auditEntry)
});

return $input.all();

模型選擇和微調

對於 HIPAA 工作流程，通用模型可以工作，但微調模型表現更好且更可預測：

基礎模型選項（通過 Ollama 本地端）：

• Llama 3.1 8B — 平衡性能和 VRAM 需求的好選擇
• Mistral 7B — 高效，對結構化任務表現良好
• Llama 3.1 70B — 更高準確率，需要更多硬體（24GB VRAM）

微調優勢：

• 訓練臨床文件摘要適配器在 3,000 個去識別化記錄上，準確率從 71% 提高到 93%
• 保險公司特定 PA 敘述格式可以燒入適配器
• 減少提示工程——適配器「知道」如何不做出診斷

使用 Ertas Studio 訓練這些適配器不需要 ML 工程師——訓練發生在你的基礎設施上，使用你去識別化的臨床資料。

常見 HIPAA 合規陷阱

日誌記錄太多： 記錄稽核元資料，但不記錄提示文字（其中可能包含 PHI）。記錄處理了什麼以及由誰處理，而不是內容。

不充分的人工監督： AI 草稿不應自動提交或儲存為最終記錄。每個工作流程需要一個明確的醫師確認步驟。

不安全的內部網絡： 「本地端」只在你的內部網絡實際上是安全的情況下才符合 HIPAA。n8n 和 Ollama 之間的通信應使用 TLS，即使是在私有網絡上。

未記錄的 AI 使用： HIPAA 要求文件記錄 PHI 如何被使用。你的 AI 使用政策需要明確涵蓋這些工作流程，包括誰可以訪問 AI 生成的草稿，以及它們如何被審閱和批准。

---

延伸閱讀

• 案例研究：n8n 機構如何為醫院網絡部署符合 HIPAA 的 AI — 真實世界的實施，包括微調適配器和完整的合規文件記錄
• 符合 HIPAA 的 AI：本地端 vs 雲端 — 合規架構比較