HIPAA 合規 AI 訓練資料：醫療保健組織實用指南

每個建構 AI 的醫療保健組織都面臨同樣的基本問題：你擁有的資料是臨床性質的，而臨床資料是 PHI。患者記錄、放射學報告、出院摘要和入院表格，這些是絕佳的 AI 訓練材料，同時也是受 HIPAA 隱私和安全規則全面保護的聯邦受保護健康信息。

本指南涵蓋 HIPAA 對 AI 訓練資料的實際要求——不是抽象的，而是 ML 工程師和合規官員可以採取行動的操作術語。它涵蓋兩種去識別化標準、臨床 AI 情境中什麼算作 PHI、為何雲端工具在結構上與 HIPAA 要求不相容，以及如何設計一個滿足隱私規則而不成為合規瓶頸的管道。

---

臨床 AI 情境中什麼算作 PHI

受保護健康信息（PHI）是由覆蓋實體或業務合作夥伴創建、接收、維護或傳輸的、可個人識別的健康信息。「可個人識別」意味著信息要麼識別個人，要麼合理地可以用來識別他們。

這個定義比大多數 ML 工程師預期的更廣泛。PHI 不只是患者姓名和社會保障號碼。它包括：

• 任何比年份更具體的日期，當與個人相關時（出生日期、入院日期、出院日期、手術日期）
• 小於州的地理細分（城市、郵遞區號、縣、街道地址）
• 年齡超過 89 歲（或當與可以識別個人的其他資料結合時的任何年齡）
• 電話號碼、傳真號碼、電子郵件地址
• IP 地址和設備識別符
• 醫療記錄號碼、健康計劃號碼、帳戶號碼
• 證書和許可證號碼
• 車輛識別符和序號
• 全臉照片和可比圖像
• 生物特徵識別符（指紋、聲紋）
• 任何其他唯一識別號碼、特徵或代碼

在臨床文件中，PHI 出現在預期的地方（標題中的患者人口統計信息）和意想不到的地方（臨床醫生在進度記錄中注明「我與患者的丈夫 John 交談了」，或嵌入文件名中的日期）。可靠的 PHI 檢測需要基於 NLP 的命名實體識別，而不只是對明顯字段進行模式匹配。

---

HIPAA 的兩種去識別化標準

HIPAA 提供且僅提供兩種方法來去識別 PHI，以產生不再受隱私規則約束的資料。

安全港（45 CFR §164.514(b)(2)）

安全港要求刪除所有 18 個指定識別符：

1. 姓名
2. 小於州的地理資料（包括郵遞區號和街道地址）
3. 直接與個人相關的日期（年份除外）
4. 電話號碼
5. 傳真號碼
6. 電子郵件地址
7. 社會保障號碼
8. 醫療記錄號碼
9. 健康計劃受益人號碼
10. 帳戶號碼
11. 證書/許可證號碼
12. 車輛識別符和序號（包括車牌）
13. 設備識別符和序號
14. 網址
15. IP 地址
16. 生物特徵識別符（指紋、視網膜掃描、聲紋）
17. 全臉照片和可比圖像
18. 任何其他唯一識別號碼、特徵或代碼

刪除所有 18 個類別後，覆蓋實體還必須沒有實際知識表明剩餘信息可以用來識別個人——即使與其他可用資料組合也不行。

安全港方法在程序上很直接，但在技術上要求很高。識別非結構化臨床文本中的所有 18 個類別需要調整良好的 NLP 管道，而不是簡單的查找和替換。

專家確定（45 CFR §164.514(b)(1)）

專家確定要求具有「適當知識和經驗，掌握使信息無法個人識別的普遍接受的統計和科學原理和方法」的人應用這些原理，並確定識別個人的風險非常小。專家的分析和結果必須記錄在案。

專家確定可以產生比安全港更不保守的去識別化——例如，如果專家可以證明剩餘日期在情境中不會造成重新識別風險，則可能不需要刪除每個日期。但是，它需要實際的專家確定，而不只是內部審查。

對於大多數醫療保健 ML 團隊，安全港是實際路徑：它被充分理解、有程序文件，且不需要為每個資料集進行外部專家參與。

---

為何雲端工具在設計上違反 HIPAA

HIPAA 的隱私規則要求 PHI 只能披露給已與覆蓋實體簽署業務合作協議（BAA）的實體，且只能用於許可目的。向雲端平台上傳 PHI 在 HIPAA 下構成「披露」。

這給基於雲端的資料準備工具帶來了結構性問題：

上傳即披露：當你將臨床文件上傳到 SaaS 平台——即使是聲稱符合 HIPAA 的平台——你正在向第三方披露 PHI。這需要 BAA。大多數 SaaS 資料準備平台不提供 BAA，或僅在有重大限制的企業計劃上提供。

BAA 不等於安全：即使有 BAA，覆蓋實體仍然有責任選擇提供「合理和適當保護措施」的業務合作夥伴。許多雲端平台的架構——共享基礎設施、多租戶儲存、第三方子處理器——對敏感臨床資料不滿足此標準。

基於雲端的 OCR 和 LLM API：許多文件處理工具將文件頁面發送到雲端 API 進行 OCR 或語言模型處理。這是額外的披露，通常沒有 BAA，且通常沒有覆蓋實體的意識。在解析掃描臨床文件時透明地調用雲端 OCR 端點的庫，是等待發生的 HIPAA 違規。

資料保留：雲端平台在備份、日誌和稽核系統中在刪除後保留資料。確保 PHI 在專案完成後從雲端平台完全清除在操作上是困難的，且通常無法驗證。

避免這些問題的唯一可靠方法是在你控制的基礎設施上處理臨床資料，沒有到外部服務的出站網路連接。

---

HIPAA 下的稽核記錄要求

HIPAA 安全規則（45 CFR §164.312(b)）要求覆蓋實體實施硬體、軟體和程序機制，記錄和檢查包含或使用電子 PHI 的信息系統中的活動。

對於 AI 訓練資料管道，這意味著：

• 訪問日誌：誰訪問了哪些文件，以及何時
• 轉換日誌：對 PHI 執行了哪些操作（解析、去識別化、標注、增強）
• 披露日誌：資料發送到哪裡（即使在內部系統內）
• 修改日誌：什麼被更改了，由誰更改

稽核日誌必須從創建日期或最後有效日期（以較晚者為準）起保留至少六年。

大多數多工具資料準備堆棧不產生共享稽核日誌。由 Docling 解析、移動到文件系統、在 Label Studio 中標注、由腳本清理的文件，沒有留下誰接觸了什麼、何時或以何種形式的統一記錄。每個工具可能有自己的內部日誌，但這些日誌未連接、不全面，且通常不是為 HIPAA 稽核目的設計的。

---

醫療保健 AI 資料準備中的常見錯誤

將「匿名化」視為等同於去識別化

從文件中刪除患者姓名不是去識別化。刪除了姓名但保留了日期、郵遞區號和提供者姓名的文件仍然可以被重新識別，特別是與其他可用資料結合時。合規要求滿足兩種 HIPAA 標準之一——安全港或專家確定——而不是部分清理。

在去識別化之前標注

人類標注員閱讀文件以進行標注。如果文件在標注時仍包含 PHI，標注步驟是一個 PHI 訪問事件，需要 HIPAA 控制——標注員必須是具有適當培訓和協議的員工成員或業務合作夥伴。在標注之前進行去識別化既更簡單，風險也更低。

使用 LLM API 進行增強

將臨床訓練範例發送到雲端 LLM API——即使是「私有」端點——以生成合成變體是 PHI 披露。用於臨床 AI 的合成資料生成必須使用本地託管模型進行，沒有出站資料傳輸。在你自己的硬體上運行帶有適當開源模型的 Ollama 是一個可行的方法。

將去識別化與 GDPR 下的匿名化混為一談

如果你也有歐洲患者資料，請注意 HIPAA 的安全港去識別化標準和 GDPR 的匿名化標準是不同的。在 HIPAA 下符合去識別化資格的資料在 GDPR 下仍可能被視為個人資料（GDPR 應用更嚴格的標準，基於重新識別是否合理可能）。如果你同時受兩者約束，根據更嚴格的標準進行設計。

---

建立 HIPAA 合規的本地管道

醫療保健 AI 訓練資料的合規管道有五個階段，全部在你控制的基礎設施上運行：

稽核日誌必須涵蓋所有五個階段，且必須足夠全面以回答：源文件是什麼，它包含什麼 PHI，刪除了什麼以及如何刪除，誰標注了去識別化版本，以及匯出了什麼。

---

Ertas Data Suite 如何解決 HIPAA 要求

Ertas Data Suite 的清理模塊使用基於 NER 的識別自動檢測和編輯 PII 和 PHI——涵蓋非結構化文字中所有 18 個安全港類別。去識別化在標注之前發生，因此人工標注員從不看到已識別的 PHI。

每個轉換——解析、編輯、標注、增強——都記錄了時間戳和操作員 ID。稽核日誌可以以適合 HIPAA 稽核請求的結構化格式匯出。增強模塊使用本地託管的 LLM（無 API 調用，無資料出口），滿足合成生成不涉及 PHI 披露的要求。

整個堆棧像桌面應用程式一樣安裝在你自己的硬體上。無需雲端帳戶，無需 BAA 談判，無需基礎設施管理。

---

相關閱讀

• 本地 AI 資料準備：受監管行業的合規指南 — 涵蓋 GDPR、HIPAA、EU AI Act 和資料主權的完整合規概述。
• 醫療保健 AI 訓練資料的 PHI 編輯 — 臨床文件中 PHI 檢測和編輯的技術深度剖析。
• 為何 RAG 在臨床資料上失敗 — 臨床文件結構如何破壞標準 RAG 管道以及替代方案。