PII 合规模式 是做什么的？
用于保护医疗应用中患者数据、临床医生数据和财务数据的模式。适用于 HIPAA (美国)、DISHA (印度)、GDPR (欧盟) 以及一般医疗数据保护。
何时使用
- 构建任何涉及患者记录的功能
- 为临床系统实现访问控制或身份验证
- 设计医疗数据的数据库模式
- 构建返回患者或临床医生数据的 API
- 实现审计追踪或日志记录
- 审查代码中的数据暴露漏洞
- 为多租户医疗系统设置行级安全 (RLS)
工作原理
医疗数据保护分为三层：分类（什么数据是敏感的）、访问控制（谁可以查看）和审计（谁实际查看了）。
数据分类
PHI（受保护健康信息）——任何可以识别患者身份且与其健康相关的数据：患者姓名、出生日期、地址、电话、电子邮件、国家身份证号码（SSN、Aadhaar、NHS 号码）、病历号、诊断、药物、化验结果、影像资料、保险单和理赔详情、预约和入院记录，或上述任何组合。
PII（医疗系统中的非患者敏感数据）：临床医生/工作人员的个人详细信息、医生费用结构和支付金额、员工薪资和银行信息、供应商付款信息。
访问控制：行级安全
ALTER TABLE patients ENABLE ROW LEVEL SECURITY;
-- 按机构限定访问范围
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')
));
-- 审计日志：仅允许插入（防篡改）
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);
审计追踪
每次 PHI 访问或修改都必须记录：
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;
}
常见泄露途径
错误消息： 切勿在抛出给客户端的错误消息中包含患者可识别数据。详细信息仅在服务端记录。
控制台输出： 切勿记录完整的患者对象。使用不透明的内部记录 ID（UUID）——不要使用病历号、国家身份证号或姓名。
URL 参数： 切勿在查询字符串或路径段中放置患者可识别数据，以免出现在日志或浏览器历史记录中。仅使用不透明的 UUID。
浏览器存储： 切勿将 PHI 存储在 localStorage 或 sessionStorage 中。仅将 PHI 保留在内存中，按需获取。
服务角色密钥： 切勿在客户端代码中使用 service_role 密钥。始终使用 anon/publishable 密钥，并让 RLS 强制实施访问控制。
日志和监控： 切勿记录完整的患者记录。仅使用不透明的记录 ID（不要使用病历号）。在将堆栈跟踪发送到错误跟踪服务之前进行清理。
数据库模式标记
在模式级别标记 PHI/PII 列：
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';
部署清单
每次部署前：
- 错误消息或堆栈跟踪中无 PHI
- console.log/console.error 中无 PHI
- URL 参数中无 PHI
- 浏览器存储中无 PHI
- 客户端代码中无 service_role 密钥
- 所有 PHI/PII 表均已启用 RLS
- 所有数据修改均有审计追踪
- 会话超时已配置
- 所有 PHI 端点均需 API 身份验证
- 跨机构数据隔离已验证
示例
示例 1：安全与不安全的错误处理
// 错误做法——在错误中泄露 PHI
throw new Error(`患者 ${patient.name} 在 ${patient.facility} 中未找到`);
// 正确做法——通用错误，详细信息在服务端使用不透明 ID 记录
logger.error('患者查找失败', { recordId: patient.id, facilityId });
throw new Error('记录未找到');
示例 2：多机构隔离的 RLS 策略
-- 机构 A 的医生无法查看机构 B 的患者
CREATE POLICY "facility_isolation"
ON patients FOR SELECT TO authenticated
USING (facility_id IN (
SELECT facility_id FROM staff_assignments WHERE user_id = auth.uid()
));
-- 测试：以机构 A 的医生身份登录，查询机构 B 的患者
-- 预期：返回 0 行
示例 3：安全日志记录
// 错误做法——记录可识别的患者数据
console.log('处理患者:', patient);
// 正确做法——仅记录不透明的内部记录 ID
console.log('处理记录:', patient.id);
// 注意：即使 patient.id 也应为不透明的 UUID，而不是病历号