com um clique
healthcare-phi-compliance
医疗应用中受保护健康信息(PHI)和个人身份信息(PII)的合规模式。涵盖数据分类、访问控制、审计追踪、加密及常见泄露途径。
Menu
医疗应用中受保护健康信息(PHI)和个人身份信息(PII)的合规模式。涵盖数据分类、访问控制、审计追踪、加密及常见泄露途径。
Instinct-based learning system that observes sessions via hooks, creates atomic instincts with confidence scoring, and evolves them into skills/commands/agents. v2.1 adds project-scoped instincts to prevent cross-project contamination.
Orchestrate building a brand-new feature end to end — research, plan, TDD implementation, review, and gated commit — by delegating each phase to the matching ECC agent. Use when adding a capability that does not exist yet.
Orchestrate bootstrapping a working MVP from a design or spec document — ingest the doc, plan thin vertical slices, scaffold the first end-to-end slice, then TDD-implement, review, and gated commit. Use to turn an SDD/PRD into a running starting point.
Orchestrate altering an existing, working feature to new desired behavior — update its tests to the new spec, change the implementation to match, review, and gated commit. Use when behavior is not broken but should be different.
Orchestrate fixing a bug — reproduce it as a failing regression test, fix to green, review, and gated commit — by delegating each phase to the matching ECC agent. Use when existing behavior is broken or wrong.
Shared orchestration engine for the orch-* skill family. Defines the gated Research-Plan-TDD-Review-Commit pipeline, the size classifier, the agent map, and the two human gates that the orch-* operation skills delegate to. Not usually invoked directly.
| name | healthcare-phi-compliance |
| description | 医疗应用中受保护健康信息(PHI)和个人身份信息(PII)的合规模式。涵盖数据分类、访问控制、审计追踪、加密及常见泄露途径。 |
| origin | Health1 Super Speciality Hospitals — contributed by Dr. Keyur Patel |
| version | 1.0.0 |
用于保护医疗应用中患者数据、临床医生数据和财务数据的模式。适用于 HIPAA(美国)、DISHA(印度)、GDPR(欧盟)以及通用医疗数据保护。
医疗数据保护在三个层面运作:分类(什么是敏感数据)、访问控制(谁能查看)和审计(谁查看了数据)。
PHI(受保护健康信息) — 任何能够识别患者身份且与其健康相关的数据:患者姓名、出生日期、地址、电话、电子邮件、国家身份证号码(SSN、Aadhaar、NHS 号码)、病历号、诊断、药物、化验结果、影像资料、保险单和理赔详情、预约和入院记录,或上述任意组合。
医疗系统中的 PII(非患者敏感数据):临床医生/员工个人详细信息、医生收费结构和支付金额、员工薪资和银行信息、供应商付款信息。
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);
每次 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。
浏览器存储: 切勿在 localStorage 或 sessionStorage 中存储 PHI。仅在内存中保留 PHI,按需获取。
服务角色密钥: 切勿在客户端代码中使用 service_role 密钥。始终使用匿名/可发布密钥,并让 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';
每次部署前:
// BAD — leaks PHI in error
throw new Error(`Patient ${patient.name} not found in ${patient.facility}`);
// GOOD — generic error, details logged server-side with opaque IDs only
logger.error('Patient lookup failed', { recordId: patient.id, facilityId });
throw new Error('Record not found');
-- Doctor at Facility A cannot see Facility B patients
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()
));
-- Test: login as doctor-facility-a, query facility-b patients
-- Expected: 0 rows returned
// BAD — logs identifiable patient data
console.log('Processing patient:', patient);
// GOOD — logs only opaque internal record ID
console.log('Processing record:', patient.id);
// Note: even patient.id should be an opaque UUID, not a medical record number