hipaa-compliance

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 而非姓名、病歷號碼、電話號碼、地址或其他識別碼。

範例

範例 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