$ loading_
帮助团队为医疗应用设计符合PHI/PII要求的数据安全与合规方案
复制安装指令，让 AI 自动完成配置 · 推荐新手
请帮我安装 askskill 上的 "healthcare-phi-compliance" 技能： 1. 下载 https://raw.githubusercontent.com/affaan-m/ECC/main/skills/healthcare-phi-compliance/SKILL.md 2. 保存为 ~/.claude/skills/healthcare-phi-compliance/SKILL.md 3. 装好后重载技能，告诉我可以用了
请为一个医疗预约与电子病历系统设计PHI/PII数据分级方案，列出数据类型、敏感级别、存储要求、传输要求，以及不同角色的访问限制。
一份结构化的数据分级表，说明各类医疗与身份信息的保护要求和访问边界。
请审查以下医疗应用API设计是否存在PHI/PII泄露风险，重点检查日志、错误信息、缓存、第三方监控、调试输出和导出功能，并给出修复建议。
一份风险清单，标明高风险泄露点、影响范围、优先级及对应整改方案。
请为医疗SaaS平台制定PHI/PII合规控制清单，覆盖最小权限访问、审计追踪、静态加密、传输加密、密钥管理、数据保留和删除策略。
一份按控制域分类的合规清单，可用于安全评审、开发实施和上线前检查。
Patterns for protecting patient data, clinician data, and financial data in healthcare applications. Applicable to HIPAA (US), DISHA (India), GDPR (EU), and general healthcare data protection.
Healthcare data protection operates on three layers: classification (what is sensitive), access control (who can see it), and audit (who did see it).
PHI (Protected Health Information) — any data that can identify a patient AND relates to their health: patient name, date of birth, address, phone, email, national ID numbers (SSN, Aadhaar, NHS number), medical record numbers, diagnoses, medications, lab results, imaging, insurance policy and claim details, appointment and admission records, or any combination of the above.
PII (Non-patient-sensitive data) in healthcare systems: clinician/staff personal details, doctor fee structures and payout amounts, employee salary and bank details, vendor payment information.
ALTER TABLE patients ENABLE ROW LEVEL SECURITY;
-- Scope access by facility
CREATE POLICY "staff_read_own_facility"
ON patients FOR SELECT TO authenticated
USING (facility_id IN (
SELECT facility_id FROM staff_assignments
WHERE user_id = auth.uid() AND role IN ('doctor','nurse','lab_tech','admin')
));
-- Audit log: insert-only (tamper-proof)
CREATE POLICY "audit_insert_only" ON audit_log FOR INSERT
TO authenticated WITH CHECK (user_id = auth.uid());
CREATE POLICY "audit_no_modify" ON audit_log FOR UPDATE USING (false);
CREATE POLICY "audit_no_delete" ON audit_log FOR DELETE USING (false);
Every PHI access or modification must be logged:
interface AuditEntry {
timestamp: string;
user_id: string;
patient_id: string;
action: 'create' | 'read' | 'update' | 'delete' | 'print' | 'export';
resource_type: string;
resource_id: string;
changes?: { before: object; after: object };
ip_address: string;
session_id: string;
}
Error messages: Never include patient-identifying data in error messages thrown to the client. Log details server-side only.
Console output: Never log full patient objects. Use opaque internal record IDs (UUIDs) — not medical record numbers, national IDs, or names.
URL parameters: Never put patient-identifying data in query strings or path segments that could appear in logs or browser history. Use opaque UUIDs only.
Browser storage: Never store PHI in localStorage or sessionStorage. Keep PHI in memory only, fetch on demand.
Service role keys: Never use the service_role key in client-side code. Always use the anon/publishable key and let RLS enforce access.
Logs and monitoring: Never log full patient records. Use opaque record IDs only (not medical record numbers). Sanitize stack traces before sending to error tracking services.
Mark PHI/PII columns at the schema level:
COMMENT ON COLUMN patients.name IS 'PHI: patient_name';
COMMENT ON COLUMN patients.dob IS 'PHI: date_of_birth';
COMMENT ON COLUMN patients.aadhaar IS 'PHI: national_id';
COMMENT ON COLUMN doctor_payouts.amount IS 'PII: financial';
Before every deployment:
…
帮助用户在回答前选择简短、标准或详细版本，控制回复深度与 token 用量。
为医疗应用部署提供患者安全自动化评估，发现风险即阻止上线。