
AI 訓練的受保護健康資訊編輯:醫療 ML 團隊的逐步指南
臨床資料用於訓練 AI 模型之前,必須識別並編輯受保護健康資訊。本指南涵蓋自動化受保護健康資訊偵測、HIPAA 去識別化標準和本地端編輯管道。
臨床資料對於 AI 訓練非常寶貴。病歷、臨床記錄、影像報告和出院摘要包含的細緻、特定領域語言,是任何數量的通用網路文字都無法替代的。但臨床資料幾乎總是包含受保護的健康資訊(PHI)——在未先完成去識別化的情況下使用它來訓練 AI 模型是違反 HIPAA 的。
對於醫療 ML 團隊,這創造了一個強制性的第一步:在任何臨床文件進入訓練管道之前,必須識別、刪除或替換受保護健康資訊,並記錄其刪除過程。本指南介紹如何正確做到這一點。
HIPAA 去識別化:兩種標準
HIPAA 提供了兩種法律認可的健康資訊去識別化方法。兩者都使資料不再受到 HIPAA 隱私規則的約束——因此在法律上可用於 AI 訓練。
安全港方法。 安全港方法要求刪除所有 18 種特定類別的識別符:
- 姓名(患者、家庭成員、雇主)
- 州級以下的地理資料(地址、城市、郵政編碼——如果地理單位包含 20,000 人以上,可以使用郵政編碼的前三位)
- 與個人相關的日期(年份除外):出生日期、入院日期、出院日期、死亡日期
- 電話號碼
- 傳真號碼
- 電子郵件地址
- 社會安全號碼
- 病歷號碼
- 健康計劃受益人號碼
- 帳號
- 證書和執照號碼
- 車輛識別符和序列號
- 設備識別符和序列號
- 網路 URL
- IP 地址
- 生物識別符(指紋、聲紋)
- 全臉照片和類似圖片
- 任何其他唯一識別號碼、特徵或代碼
刪除所有 18 類別後,涵蓋實體還必須對剩餘資訊沒有實際知識表明它可以識別個人。最後這個條件是讓團隊措手不及的。臨床記錄可能不包含任何 18 個明確的識別符,但仍然可以識別身份,因為它描述了資料集中只有一位患者患有的罕見疾病。
專家確定方法。 具有統計知識的專家應用普遍接受的原則,確定識別個人的風險非常小。這種方法更靈活——它不需要刪除所有 18 種識別符類型——但需要有文件記錄的統計依據。對於大多數醫療 AI 團隊來說,安全港是實際的選擇,因為它提供了一個清晰的清單且更易於稽核。
為何手動審查無法擴展
在自動化受保護健康資訊偵測工具出現之前,去識別化是手動進行的:臨床醫生或受過訓練的審查員閱讀每份文件並手動編輯識別符。對於 500 份文件的資料集,這是可行的。對於 50,000 份臨床記錄的資料集,則不然。
單份臨床記錄平均 600-800 個字。每小時能處理 20 份記錄的審查員——這需要專注力和領域知識——審查 50,000 份記錄需要 2,500 小時。這超過一個人一年多的工作時間,而且隨著資料集大小線性增長。
使用命名實體識別(NER)的自動化受保護健康資訊偵測是在規模上唯一實際的方法。訓練良好的受保護健康資訊偵測模型每分鐘處理數百份文件,標記每個識別出的受保護健康資訊實例及其位置和類別,並生成可供人工抽查(而非完整閱讀)的審查就緒輸出。
陷阱:沒有自動化工具能達到 100% 的受保護健康資訊召回率。每次對自動化去識別化工具的評估都發現了殘留的假陰性率——工具遺漏的受保護健康資訊。對於 AI 訓練資料準備,這意味著自動化偵測必須跟隨結構化的人工審查流程,而非取代它。
自動化工具會遺漏什麼
18 個安全港識別符並非同樣容易偵測。現代 NER 模型可以可靠地偵測姓名、日期和聯繫資訊。更難的情況是:
間接識別符。 臨床記錄寫道「患者,一位來自蒙大拿州農村的 67 歲斯瓦希里語女性,出現……」不包含任何 18 種明確識別符類型,但在小型人口中,這些特徵的組合可能使患者可識別。自動化工具在沒有關於人口規模的外部參考資料的情況下無法偵測這類識別符。
罕見疾病組合。 患有罕見疾病、特定基因變異和不尋常合併症組合的患者,即使刪除了所有 18 個識別符,也可能事實上可識別。專家確定方法論解決了這個問題;安全港方法沒有。
嵌入文字中的數字識別符。 自由文字敘述中嵌入的病歷號碼和帳號——「MRN: 4471832 入院……」——通常可以被偵測到。但嵌入非標準格式的識別符——「患者在該機構以 4471832 登記」——可能被在標準格式上訓練的模型遺漏。
醫療服務提供者和機構識別符。 HIPAA 的安全港類別側重於患者識別符。但臨床記錄通常按名稱命名特定的醫療服務提供者、機構和主治醫生。在小型診所或只有少數醫療服務提供者治療特定疾病的專科中,醫療服務提供者姓名可以使患者重新識別。這些也應該編輯,儘管安全港並未嚴格要求。
跨文件關聯。 單份去識別化文件可能是安全的。來自同一患者的一組去識別化文件,合在一起可能可以重新識別,因為日期、病情和手術的組合將人口縮小到一個人。這是一個語料庫級別的風險,文件級別的自動化工具無法評估。
編輯管道
AI 訓練資料的完整受保護健康資訊編輯管道有五個階段。
第一階段:偵測。 在所有文件上運行自動化基於 NER 的受保護健康資訊偵測。輸出是偵測到的受保護健康資訊實例列表:文件 ID、字元偏移量、實體類別、實體文字和置信度分數。使用專門為臨床文字訓練的模型——在新聞或網路文字上訓練的通用 NLP NER 模型在臨床記錄上表現差,因為語言模式不同。針對結構化欄位(表單、表格)和非結構化敘述的單獨模型比單一模型更準確。
第二階段:審查。 將偵測到的受保護健康資訊實例呈現給人工審查員確認。審查介面應在上下文中顯示每個偵測到的實例,允許審查員確認、覆蓋或添加遺漏的實例,並記錄每個審查員的決定。對於高置信度偵測(置信度大於 0.95),批量確認是合適的。低置信度偵測需要個別審查。審查員還應閱讀未偵測到受保護健康資訊的文件樣本,以估計假陰性率。
第三階段:編輯。 將編輯應用於文件。編輯可以是替換(用佔位符如「[PATIENT]」替換姓名)或刪除(完全刪除文字)。對於 NLP 訓練資料,強烈優先選擇替換——刪除在文字中創建空白,破壞句子結構,可能導致下游解析錯誤。替換在刪除識別內容的同時保持文件流暢性。在可能的情況下,用聽起來真實但非真實的值替換(用不同的合理同名替換姓名)能更好地保留模型將學習的語言模式。
第四階段:驗證。 對編輯後的文件進行第二次受保護健康資訊偵測,以捕獲殘留識別符。第二次假陰性率應顯著低於第一次(因為大多數識別符已被刪除),但這是必要的品質檢查。在第二次通過中偵測到的任何受保護健康資訊都是 管道失敗,應觸發審查第一次為何遺漏它。
第五階段:記錄。 每次偵測、審查決定和編輯都必須記錄時間戳記、審查員 ID、文件 ID 和具體的識別符類別。這個日誌就是稽核軌跡。如果監管機構詢問「這個資料集是如何去識別化的?」,答案就是這個日誌——而非政策文件。
為何稽核日誌不可或缺
HIPAA 不僅要求去識別化。它要求去識別化以可以由民權辦公室(OCR)在調查時審查的方式記錄。
如果您訓練了一個臨床 NLP 模型,後來面臨訓練資料包含受保護健康資訊的投訴,辯護是稽核日誌:「以下是每份被處理的文件。以下是每個被偵測到的受保護健康資訊實例。以下是每個審查決定。以下是每次應用的編輯。以下是第二次驗證結果。」沒有這個日誌,您就沒有辯護。
對於構建訓練資料集的醫療 AI 團隊,稽核日誌不是行政開銷。它是流程已被遵循的證據。
受保護健康資訊編輯:本地端 vs. 雲端
受保護健康資訊編輯在哪裡運行在法律上具有重要意義。將臨床記錄通過雲端 API 進行受保護健康資訊偵測,意味著受保護健康資訊被傳輸到第三方系統並由其處理。在 HIPAA 下,這需要與雲端供應商簽訂業務夥伴協議(BAA)。一些雲端供應商提供業務夥伴協議;許多不提供。
更重要的是:即使有業務夥伴協議,資料也已脫離醫療組織的控制。傳輸是一個風險事件。如果資料在傳輸過程中被攔截或被 API 供應商保留超過約定時間,那是潛在的資安事故。
最安全的方法——也是大多數醫療合規團隊要求的方法——是完全在本地端運行受保護健康資訊偵測和編輯,在組織控制的硬體上。資料從不離開。不需要業務夥伴協議。沒有傳輸風險。稽核日誌保留在組織系統內。
對於 AI 訓練資料具體而言,資料集規模大且隨著新資料添加而重複運行處理管道,本地端操作也更實際。將 50,000 份臨床記錄發送到雲端 API 既昂貴、緩慢,又受速率限制。在本地工作站或伺服器上運行相同的管道,在初始設置後更快且免費。
Your data is the bottleneck — not your models.
Ertas Data Suite turns unstructured enterprise files into AI-ready datasets — on-premise, air-gapped, with full audit trail. One platform replaces 3–7 tools.
相關閱讀
- Clinical NLP Training Data: How to Prepare Medical Records Without Violating HIPAA — 臨床 NLP 資料集準備的完整管道
- Why Vector RAG Fails on Clinical Data — and What to Use Instead — 了解 RAG 在醫療術語上的限制
- HIPAA-Compliant AI Training Data Guide — AI 團隊的全面 HIPAA 框架
Turn unstructured data into AI-ready datasets — without it leaving the building.
On-premise data preparation with full audit trail. No data egress. No fragmented toolchains. EU AI Act Article 30 compliance built in.
Keep reading

HIPAA-Compliant AI Training Data: A Practical Guide for Healthcare Organizations
What HIPAA actually requires for AI training data — PHI identification, de-identification standards, and how to build a compliant on-premise data preparation pipeline for healthcare ML teams.

Best HIPAA-Compliant RAG Pipeline for Healthcare: On-Premise Document Retrieval Without Data Egress
Healthcare organizations need RAG for clinical AI — but cloud-based retrieval pipelines violate HIPAA when they process PHI. Here is how to build a compliant RAG pipeline that runs entirely on your infrastructure.

How to Generate EU AI Act Technical Documentation from Your Data Pipeline
Practical guide to producing EU AI Act-compliant technical documentation from your data preparation pipeline — covering data lineage, transformation logs, quality metrics, and operator attribution.