zsp/everything-claude-code
1
0
Fork 0
mirror of https://github.com/affaan-m/everything-claude-code.git synced 2026-03-30 13:43:26 +08:00
Code Issues Packages Projects Releases Wiki Activity

fix: address all CodeRabbit + Cubic review comments on PR #955

Browse Source 
CodeRabbit fixes (6 comments):
- All 4 skills: renamed 'When to Activate' → 'When to Use', added 'How It Works' and 'Examples' sections
- CDSS: DoseValidationResult.suggestedRange now typed as '| null'
- PHI: hyphenated 'Non-patient-sensitive'

Cubic fixes (7 issues):
- P1: CDSS weight-based check now BLOCKS when weight missing (was false-negative pass)
- P1: EMR medication safety clarified — critical = hard block, override requires documented reason
- P1: PHI logging guidance clarified — use opaque UUIDs only, not medical record numbers
- P2: CDSS validateDose now uses age and renal function params (ageAdjusted, renalAdjusted rules)
- P2: Eval CI example now enforces 95% threshold with jq + bc calculation
- P2: Eval CI example now includes --coverage --coverageThreshold on CDSS suite
- P2: CDSS suggestedRange null type fixed (same as CodeRabbit)
This commit is contained in:
Dr. Keyur Patel
2026-03-27 03:54:20 +00:00
parent 63737544a1
commit e3f2bda9fc
4 changed files with 356 additions and 355 deletions
Download Patch File Download Diff File Expand all files Collapse all files

203
skills/healthcare-phi-compliance/SKILL.md
View File

@@ -12,7 +12,7 @@ rollback: "git revert"
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.
## When to Activate
## When to Use
- Building any feature that touches patient records
- Implementing access control or authentication for clinical systems
@@ -22,124 +22,37 @@ Patterns for protecting patient data, clinician data, and financial data in heal
- Reviewing code for data exposure vulnerabilities
- Setting up Row-Level Security (RLS) for multi-tenant healthcare systems
## Data Classification
## How It Works
### PHI (Protected Health Information)
Healthcare data protection operates on three layers: **classification** (what is sensitive), **access control** (who can see it), and **audit** (who did see it).
Any data that can identify a patient AND relates to their health:
### Data Classification
- 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
- Any combination of the above
**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 (Personally Identifiable Information)
**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.
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
## Access Control Patterns
### Row-Level Security (Supabase/PostgreSQL)
### Access Control: Row-Level Security
```sql
-- Enable RLS on every PHI table
ALTER TABLE patients ENABLE ROW LEVEL SECURITY;
-- Scope access by facility/centre
-- 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 (no updates, no deletes)
CREATE POLICY "audit_insert_only"
ON audit_log FOR INSERT
TO authenticated
WITH CHECK (user_id = auth.uid());
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);
```
### API Authentication
- Every API route handling PHI MUST require authentication
- Use short-lived tokens (JWT with 15-min expiry for clinical sessions)
- Implement session timeout (auto-logout after inactivity)
- Log every PHI access with user ID, timestamp, and resource accessed
## Common Leak Vectors (Check Every Deployment)
### 1. Error Messages
```typescript
// ❌ BAD — leaks PHI in error
throw new Error(`Patient ${patient.name} not found in ${patient.facility}`);
// ✅ GOOD — generic error, log details server-side
logger.error('Patient lookup failed', { patientId, facilityId });
throw new Error('Record not found');
```
### 2. Console Output
```typescript
// ❌ BAD
console.log('Processing patient:', patient);
// ✅ GOOD
console.log('Processing patient:', patient.id); // ID only
```
### 3. URL Parameters
```
❌ /patients?name=John+Doe&dob=1990-01-01
✅ /patients/uuid-here (lookup by opaque ID)
```
### 4. Browser Storage
```typescript
// ❌ NEVER store PHI in localStorage/sessionStorage
localStorage.setItem('currentPatient', JSON.stringify(patient));
// ✅ Keep PHI in memory only, fetch on demand
const [patient, setPatient] = useState<Patient | null>(null);
```
### 5. Service Role Keys
```typescript
// ❌ NEVER use service_role key in client-side code
const supabase = createClient(url, SUPABASE_SERVICE_ROLE_KEY);
// ✅ ALWAYS use anon key — let RLS enforce access
const supabase = createClient(url, SUPABASE_ANON_KEY);
```
### 6. Logs and Monitoring
- Never log full patient records
- Log patient IDs, not names
- Sanitize stack traces before sending to error tracking services
- Ensure log storage itself is access-controlled
## Audit Trail Requirements
### Audit Trail
Every PHI access or modification must be logged:
@@ -151,35 +64,85 @@ interface AuditEntry {
action: 'create' | 'read' | 'update' | 'delete' | 'print' | 'export';
resource_type: string;
resource_id: string;
changes?: { before: object; after: object }; // for updates
changes?: { before: object; after: object };
ip_address: string;
session_id: string;
}
```
## Database Schema Tagging
### Common Leak Vectors
Mark PHI/PII columns at the schema level so automated tools can identify them:
**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.
### Database Schema Tagging
Mark PHI/PII columns at the schema level:
```sql
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';
COMMENT ON COLUMN employees.salary IS 'PII: financial';
```
## Deployment Checklist
### Deployment Checklist
Before every deployment of a healthcare application:
Before every deployment:
- No PHI in error messages or stack traces
- No PHI in console.log/console.error
- No PHI in URL parameters
- No PHI in browser storage
- No service_role key in client code
- RLS enabled on all PHI/PII tables
- Audit trail for all data modifications
- Session timeout configured
- API authentication on all PHI endpoints
- Cross-facility data isolation verified
- [ ] No PHI in error messages or stack traces
- [ ] No PHI in console.log/console.error
- [ ] No PHI in URL parameters
- [ ] No PHI in browser storage
- [ ] No service_role key in client code
- [ ] RLS enabled on all PHI/PII tables
- [ ] Audit trail for all data modifications
- [ ] Session timeout configured
- [ ] API authentication on all PHI endpoints
- [ ] Cross-facility data isolation verified
## Examples
### Example 1: Safe vs Unsafe Error Handling
```typescript
// 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');
```
### Example 2: RLS Policy for Multi-Facility Isolation
```sql
-- 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
```
### Example 3: Safe Logging
```typescript
// 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
```