一、技能概述
该技能用于构建涉及患者记录的功能、实施临床系统访问控制、设计医疗数据数据库模式、构建返回患者或临床医生数据的 API、实施审计追踪或日志记录，以及审查代码是否存在数据暴露漏洞。它基于三层防护模型运作：分类（识别哪些数据是敏感的）、访问控制（谁可以查看）、审计（谁查看过）。
适用法规范围：HIPAA（美国）、DISHA（印度）、GDPR（欧盟）及通用医疗数据保护。
二、核心功能
1. 数据分类（Data Classification）
技能明确定义了医疗健康系统中需要保护的数据类型：
| 类别 | 包含内容 |
|---|---|
| PHI（受保护健康信息） | 患者姓名、出生日期、地址、电话、邮箱、身份证号（SSN、Aadhaar、NHS号）、病历号、诊断、用药、化验结果、影像、保险单及理赔详情、就诊记录 |
| PII（个人身份信息） | 临床医生/员工个人详情、医生收费结构及付款金额、员工薪资和银行信息、供应商支付信息 |
2. 行级安全（Row-Level Security）
技能提供了基于 PostgreSQL RLS 的访问控制实现模式：
-- 启用 RLS
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);
3. 审计追踪（Audit Trail）
每次 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;
}
4. 常见泄露向量防护
技能明确列出了必须防范的数据泄露途径：
| 泄露向量 | 防护措施 |
|---|---|
| 错误消息 | 绝不向客户端返回包含患者身份信息的错误消息，详细信息仅记录在服务端日志 |
| 控制台输出 | 绝不记录完整患者对象，使用不透明的内部记录 ID（UUID）替代病历号、身份证号或姓名 |
| URL 参数 | 绝不将患者身份信息放在查询字符串或路径段中，使用不透明 UUID |
| 浏览器存储 | 绝不将 PHI 存储在 localStorage 或 sessionStorage 中，仅在内存中保持，按需获取 |
| Service Role 密钥 | 绝不在客户端代码中使用 service_role 密钥，始终使用 anon/publishable 密钥，由 RLS 强制访问控制 |
| 日志与监控 | 绝不记录完整患者记录，仅使用不透明记录 ID（非病历号），发送到错误追踪服务前需清洗堆栈追踪 |
5. 数据库模式标记（Database Schema Tagging）
在数据库模式层面标记 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';
6. 代码示例
Example 1：安全与不安全的错误处理
// ❌ 不安全——泄露 PHI
throw new Error(`Patient ${patient.name} not found in ${patient.facility}`);
// ✅ 安全——通用错误，详细信息服务端记录
logger.error('Patient lookup failed', { recordId: patient.id, facilityId });
throw new Error('Record not found');
Example 3：安全日志记录
// ❌ 不安全——记录可识别患者的数据
console.log('Processing patient:', patient);
// ✅ 安全——仅记录不透明内部记录 ID
console.log('Processing record:', patient.id);
// 注意：patient.id 应为不透明 UUID，而非病历号
三、主要用途
-
医疗数据系统开发 —— 构建涉及患者记录、临床系统或医疗 API 时建立合规防护
-
访问控制与认证设计 —— 为临床系统实施认证、授权和行级安全策略
-
数据库模式设计 —— 设计医疗数据表结构时识别并标记 PHI/PII 列
-
代码审查与漏洞排查 —— 审查代码中是否存在数据暴露漏洞
-
多租户医疗系统隔离 —— 设置 RLS 确保跨机构数据隔离
-
审计追踪实施 —— 为所有数据修改和访问建立防篡改审计日志
四、部署前检查清单
在每次部署前，必须逐项确认：
-
错误消息和堆栈追踪中不含 PHI
-
console.log/console.error中不含 PHI -
URL 参数中不含 PHI
-
浏览器存储中不含 PHI
-
客户端代码中不含 service_role 密钥
-
所有 PHI/PII 表已启用 RLS
-
所有数据修改有审计追踪
-
会话超时已配置
-
所有 PHI 端点有 API 认证
-
跨机构数据隔离已验证
五、重要原则
-
分类先行 —— 先识别哪些数据是 PHI/PII，再设计保护措施
-
RLS 强制隔离 —— 使用数据库行级安全作为访问控制的最后一道防线
-
审计不可篡改 —— 审计日志应仅允许插入，不允许更新或删除
-
绝不记录完整患者对象 —— 使用不透明 UUID 替代可识别信息
-
客户端永不使用 service_role —— 始终通过 RLS 控制访问
-
错误消息脱敏 —— 用户端只返回通用错误，详细信息仅服务端可见
-
多层防护 —— 分类、访问控制、审计三层协同工作
-
数据库级标记 —— 在模式层标记 PHI/PII 列，便于自动化扫描和合规审计
六、总结
Healthcare PHI Compliance 是一套医疗健康数据合规与 PHI/PII 防护的完整实践技能，覆盖数据分类、行级安全（RLS）、审计追踪、泄露向量防护、数据库模式标记和部署检查等核心领域。它提供了可直接落地的 SQL 策略模板、审计接口定义和代码示例，适用于 HIPAA、DISHA、GDPR 等多法规场景。该技能适用于医疗健康系统开发者、架构师和安全审查人员在构建涉及患者数据的系统、实施访问控制、设计数据库模式和审计代码等场景。
