HIPAA 合規性

HIPAA 合規性 是做什麼的？

當任務明確關於美國醫療保健合規性時，將其作為 HIPAA 專用入口。此技能被刻意設計為精簡且標準化：

• healthcare-phi-compliance 仍然是處理 PHI/PII 處理、資料分類、稽核日誌、加密和洩漏防護的主要實作技能。
• healthcare-reviewer 仍然是當程式碼、架構或產品行為需要醫療保健意識的二次審查時的專門審查者。
• security-review 仍然適用於一般身份驗證、輸入處理、秘密、API 和部署強化。

何時使用

• 請求明確提及 HIPAA、PHI、受保實體、業務合作夥伴或 BAA
• 建立或審查儲存、處理、匯出或傳輸 PHI 的美國醫療保健軟體
• 評估日誌、分析、LLM 提示、儲存或支援工作流程是否造成 HIPAA 曝險
• 設計需要最小必要存取權限和可稽核性的患者面向或臨床醫生面向系統

運作方式

將 HIPAA 視為在更廣泛的醫療保健隱私技能之上的覆蓋層：

1. 從 healthcare-phi-compliance 開始，獲取具體的實作規則。
2. 應用 HIPAA 特定的決策關卡：
   • 此資料是否為 PHI？
   • 此行爲者是否為受保實體或業務合作夥伴？
   • 供應商或模型提供者在接觸資料前是否需要 BAA？
   • 存取權限是否限制在最小必要範圍？
   • 讀取/寫入/匯出事件是否可稽核？
3. 如果任務影響患者安全、臨床工作流程或受監管的生產架構，則升級至 healthcare-reviewer。

HIPAA 特定護欄

• 切勿將 PHI 置於日誌、分析事件、崩潰報告、提示或客戶可見的錯誤字串中。
• 切勿在 URL、瀏覽器儲存、螢幕截圖或複製的範例負載中暴露 PHI。
• PHI 的讀取和寫入需要經過身份驗證的存取、範圍授權和稽核軌跡。
• 預設封鎖第三方 SaaS、可觀測性、支援工具和 LLM 提供者，直到其 BAA 狀態和資料邊界明確為止。
• 遵循最小必要存取原則：正確的使用者應僅能看到完成任務所需的最小 PHI 片段。
• 偏好使用不透明的內部 ID，而非姓名、MRN、電話號碼、地址或其他識別符。

範例

範例 1：以 HIPAA 為框架的產品請求

使用者請求：

在我們的臨床醫生儀表板中新增 AI 生成的訪視摘要。我們服務美國診所，需要保持 HIPAA 合規。

回應模式：

• 啟用 hipaa-compliance
• 使用 healthcare-phi-compliance 審查 PHI 的移動、日誌、儲存和提示邊界
• 在傳送任何 PHI 之前，驗證摘要提供者是否受到 BAA 覆蓋
• 如果摘要影響臨床決策，則升級至 healthcare-reviewer

範例 2：供應商/工具決策

使用者請求：

我們可以將支援對話記錄和患者訊息傳送到我們的分析堆疊中嗎？

回應模式：

• 假設這些訊息可能包含 PHI
• 除非分析供應商已獲批准用於 HIPAA 綁定的工作負載且資料路徑已最小化，否則封鎖此設計
• 在可能的情況下，要求進行去識別化處理或採用非 PHI 的事件模型

相關技能

• healthcare-phi-compliance
• healthcare-reviewer
• healthcare-emr-patterns
• healthcare-eval-harness
• security-review