HIPAA 合規 是做什麼的?
當任務明確與美國醫療保健合規相關時,使用此技能作為 HIPAA 的特定入口。此技能刻意保持精簡且權威:
healthcare-phi-compliance仍是 PHI/PII 處理、資料分類、稽核記錄、加密及洩漏防護的主要實作技能。healthcare-reviewer仍是專門的審查員,當程式碼、架構或產品行為需要醫療保健意識的第二重檢查時使用。security-review仍適用於一般的身分驗證、輸入處理、機密、API 及部署強化。
使用時機
- 請求明確提及 HIPAA、PHI、涵蓋實體、業務合作夥伴或 BAA
- 建置或審查儲存、處理、匯出或傳輸 PHI 的美國醫療保健軟體
- 評估日誌、分析、LLM 提示、儲存或支援工作流程是否會造成 HIPAA 暴露風險
- 設計面向患者或臨床醫生的系統,其中最低必要存取和可稽核性至關重要
運作方式
將 HIPAA 視為更廣泛醫療保健隱私技能的上層覆蓋:
- 從
healthcare-phi-compliance開始,取得具體的實作規則。 - 套用 HIPAA 特定的決策關卡:
- 此資料是否為 PHI?
- 此行為者是否為涵蓋實體或業務合作夥伴?
- 廠商或模型提供者是否需要 BAA 才能接觸資料?
- 存取權限是否限制在最低必要的範圍內?
- 讀取/寫入/匯出事件是否可稽核?
- 如果任務影響患者安全、臨床工作流程或受法規規範的生產架構,則升級至
healthcare-reviewer。
HIPAA 特定護欄
- 絕不要將 PHI 置於日誌、分析事件、崩潰報告、提示或客戶可見的錯誤字串中。
- 絕不要將 PHI 暴露於 URL、瀏覽器儲存、螢幕截圖或複製的範例有效負載中。
- 對於 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-compliancehealthcare-reviewerhealthcare-emr-patternshealthcare-eval-harnesssecurity-review