最佳符合HIPAA的醫療RAG管道：無資料外洩的本地文件檢索

檢索增強生成是每個值得部署的臨床AI助手背後的架構。醫生提出問題，系統檢索相關的臨床文件，語言模型基於這些文件合成答案。這個模式是有效的。合規問題在於這些文件在檢索過程中去了哪裡。

當RAG管道將臨床筆記發送到外部嵌入API時，這些筆記——包含病患姓名、病歷號、診斷和治療歷史——離開了您的基礎設施。根據HIPAA，這構成向第三方揭露受保護健康資訊（PHI）。即使API提供商簽署了商業夥伴協議，您也已經引入了資料外洩、擴大了攻擊面，並建立了對您無法控制其基礎設施的供應商的依賴。

本文解釋了如何建構符合HIPAA的最佳RAG管道：將每個位元組的PHI保留在您自己的伺服器上，在嵌入前編輯識別碼，並維護滿足45 CFR 164.312要求的完整稽核追蹤。

HIPAA對RAG管道的實際要求

大多數RAG教學完全跳過合規性。但如果您的管道接觸PHI——而臨床文件幾乎總是包含PHI——四類HIPAA要求直接適用。

**技術保障措施（45 CFR 164.312(a)）**要求對任何儲存或處理ePHI的系統實施存取控制。您的向量資料庫、嵌入模型、文件儲存——都需要唯一使用者識別、緊急存取程序、自動登出和加密。使用共享API金鑰的雲端託管向量資料庫不滿足這一要求。

**稽核控制（45 CFR 164.312(b)）**要求具備硬體、軟體和程序機制來記錄和審查包含ePHI的系統中的活動。每次文件擷取、每次嵌入操作、每次檢索查詢都需要日誌條目。「我們使用LangChain」不是稽核追蹤。

**完整性控制（45 CFR 164.312(c)）**要求具備驗證ePHI並保護其免受不當變更或銷毀的機制。您的管道必須確保文件在分塊、嵌入或檢索過程中不會損壞。

**傳輸安全（45 CFR 164.312(e)）**要求對透過網路傳輸的ePHI進行加密。在雲端RAG設定中，每個傳輸文件分塊的API呼叫都是必須加密的傳輸。在氣隙隔離的RAG管道中，沒有需要保護的傳輸——因為資料從未離開機器。

最小必要標準（45 CFR 164.502(b)）增加了另一個約束：您應該只處理完成任務所需的最少PHI。如果您的檢索系統只需要筆記的臨床內容——而不是病患姓名、出生日期或病歷號——這些識別碼應在進入管道之前被移除。

合規RAG的三層架構

建構面向醫療資料的最佳RAG解決方案需要三層協同工作：嵌入前編輯、隔離基礎設施、記錄一切。

第一層：嵌入前編輯

大多數RAG架構直接嵌入原始文件。在醫療領域，這意味著PHI被編碼到向量表示中並儲存在向量資料庫中。儘管向量不是人類可讀的，但它們源自PHI，可能受HIPAA保護。

更安全的方法：在文件被分塊和嵌入之前去除PHI。病患姓名變為[病患]。病歷號變為[病歷號]。出生日期變為[出生日期]。臨床內容——診斷、手術、藥物、實驗室數值——保持完整，因為這才是檢索系統真正需要的。

這不僅僅是合規措施，也是更好的工程實務。嵌入模型不需要病患姓名來理解一份筆記描述的是一位服用二甲雙胍、A1C為8.2的糖尿病病患。移除識別碼可以減少雜訊，將向量空間聚焦於臨床相關語義。

第二層：隔離基礎設施

氣隙隔離的RAG管道完全在本地基礎設施上運行，無需網際網路連線。嵌入模型在本地運行。向量儲存在本地運行。用於生成的語言模型在本地運行。無API呼叫，無資料外洩，無第三方依賴。

這消除了整整一類HIPAA風險。沒有需要設定的傳輸安全，因為沒有傳輸。沒有需要協商的BAA，因為沒有商業夥伴。攻擊面縮小到您自己的網路邊界。

第三層：記錄一切

HIPAA稽核控制不是可選的。進入管道的每個文件、套用的每次轉換、執行的每個查詢和返回的每個結果都必須記錄時間戳和操作人員識別。這不僅僅是為了通過稽核——而是為了可重現性和除錯。

當臨床醫生質疑檢索結果時，您需要追溯其來源：哪個文件的哪個版本被分塊了，如何嵌入的，套用了什麼編輯，以及何時進行的。沒有這個追蹤鏈，您無法驗證合規性或正確性。

Ertas如何建構符合HIPAA的RAG管道

Ertas Data Suite是一款本地部署的桌面應用程式，配備專為這一工作流設計的視覺化管道建構器。以下是醫療文件RAG管道的節點連接方式。

Source節點擷取臨床文件——出院摘要、病程紀錄、手術報告、DICOM中繼資料。文件保留在本地檔案系統中。沒有上傳步驟，沒有雲端暫存區。

Quality Scorer節點在處理繼續之前評估每個文件的完整性、格式一致性和編碼問題。格式錯誤的文件、截斷的筆記和損壞的檔案在這裡被標記——而不是在它們已經汙染您的向量儲存之後。

PII Redactor節點使用模式比對和針對臨床文字調校的NER模型偵測並移除PHI。它捕獲病歷號、病患姓名、社會安全號碼、地址、出生日期、電話號碼和其他HIPAA安全港識別碼。編輯發生在任何嵌入之前。

Anomaly Detector節點識別統計異常值——長度異常的文件、非預期的字元分佈或與語料庫顯著偏離的內容。在臨床資料中，異常通常表示掃描錯誤、錯誤路由的文件或應在嵌入前審查的資料輸入問題。

分塊和嵌入將編輯後的文件分割為檢索適用大小的片段，並使用本地託管的模型生成向量嵌入。不呼叫OpenAI、Cohere或任何外部服務的API。嵌入模型與管道的其餘部分在同一台機器上運行。

向量儲存輸出將嵌入寫入本地向量資料庫——ChromaDB、Qdrant、Milvus、Weaviate或FAISS。向量儲存永遠不會離開您的基礎設施。檢索查詢在本地執行。

每個步驟都被記錄。稽核追蹤記錄了哪個操作人員運行了管道、處理了哪些文件、套用了哪些編輯、每次轉換何時發生以及輸出是什麼樣的。這同時滿足45 CFR 164.312(b)下的HIPAA稽核要求和歐盟AI法案第30條的日誌記錄要求。

對比：雲端RAG vs. 自託管腳本 vs. Ertas本地部署

自託管方法可以做到合規，但需要自行建構和維護編輯、稽核和隔離基礎設施。對於沒有專門ML工程團隊的組織，Ertas提供了面向企業使用的最佳氣隙RAG工具，無需自訂開發負擔。

實際場景：從臨床筆記到可檢索的知識庫

考慮一家200張床位的醫院為其住院醫師建構臨床AI助手。目標：醫生輸入關於病患病情的問題，系統從醫院自己的臨床文件中檢索相關段落——過去的出院摘要、治療方案和臨床指南。

該醫院擁有八年間累積的850,000份臨床筆記。大約15%包含來自舊版EHR遷移的掃描偽影或格式問題。所有筆記都包含PHI。

沒有合規管道，團隊需要：編寫自訂去識別化腳本，根據安全港要求進行驗證，設定本地嵌入模型，設定向量資料庫，建構分塊邏輯，實作稽核日誌記錄，並維護所有這些。預計時間線：四到六個月，需要兩名ML工程師和一名合規官。

使用Ertas，管道作為視覺化工作流運行：Source（臨床筆記目錄）連接到Quality Scorer（標記15%有格式問題的文件以供審查）連接到PII Redactor（去除所有18個安全港識別碼）連接到Anomaly Detector（捕獲剩餘異常值）連接到嵌入和向量儲存輸出。稽核追蹤自動生成。整個管道在一台工作站上運行，無需網際網路連線。預計時間線：數天，而非數月。

生成的向量儲存包含經PHI編輯的臨床知識，醫生可以透過任何本地託管的LLM進行查詢。病患隱私得到保護。稽核追蹤記錄了每次文件轉換。醫院的合規官可以隨時查看日誌。

稽核追蹤優勢

具有稽核追蹤功能的RAG管道不僅僅是合規核取方塊，更是一個診斷工具。

當檢索結果看起來不對——AI助手呈現了不相關的段落，或臨床醫生質疑某個建議——稽核追蹤讓您追溯結果到其來源。您可以識別該段落來自哪個文件，驗證編輯是否正確套用，檢查分塊是否以遺失上下文的方式分割了文件，並確認嵌入模型版本自擷取以來未發生變化。

這種可追溯性是區分原型和生產系統的關鍵。這也是稽核員和合規官在HIPAA安全評估中尋找的內容。他們不想看到您有一個RAG系統。他們想看到對於任何給定的輸出，您能展示從來源文件到檢索結果的完整保管鏈。

Ertas記錄每次轉換的時間戳、操作人員ID、節點設定和輸入/輸出校驗和。這與支援歐盟AI法案第30條技術文件要求的日誌基礎設施相同——這意味著一個管道同時滿足美國和歐盟的監管框架。

建構您的符合HIPAA的RAG管道

探索本地RAG基礎設施的醫療機構可以加入Ertas設計合作夥伴計畫。設計合作夥伴可獲得管道建構器的早期存取權限、對臨床NLP功能的直接輸入，以及在其環境中建構敏感文件最佳RAG管道的實務支援。

如果您的組織處理PHI並需要無資料外洩的檢索增強生成，本文描述的架構——嵌入前編輯、隔離基礎設施、記錄一切——是通往生產的路徑。Ertas Data Suite讓這條路徑更短。