Compliance and Safety

CareBridge handles Protected Health Information (PHI) and surfaces AI-driven clinical flags, so compliance is a first-class concern rather than an afterthought. This page summarizes the safety and regulatory posture; each section links to its authoritative runbook in the source repo.

PHI encryption

PHI columns are encrypted with AES-256-GCM using a 32-byte key from PHI_ENCRYPTION_KEY (hex-encoded), read at runtime by a Drizzle custom type. A second key, PHI_ENCRYPTION_KEY_PREVIOUS, acts as a decryption fallback so rotation can be gradual. HMAC indexes (e.g. mrn_hmac) use a separate PHI_HMAC_KEY that must never be rotated with the same procedure.

Routine and emergency rotation are documented step-by-step, including a keyset-paginated re-encryption script and post-rotation sanity checks. The long-term plan is envelope encryption against a managed KMS. See the PHI key rotation runbook.

HIPAA audit log

CareBridge retains audit records for 7 years (one year beyond the HIPAA Security Rule minimum of 6, as a safety buffer). The audit_log table is append-only and tamper-evident at the database level:

• Row triggers block per-row UPDATE and DELETE.
• A statement trigger blocks TRUNCATE (which bypasses row-level triggers).
• UPDATE / DELETE / TRUNCATE are REVOKEd from the PUBLIC pseudo-role as defense-in-depth.

A known limitation is that the table owner can DROP TRIGGER, so the migration role and the runtime application role must be distinct — the app runs with INSERT only. Only audit_log satisfies the HIPAA tamper-evidence requirement; review_jobs is supplementary operational state. Full policy, including PHI handling for review_jobs.rules_output, in the HIPAA retention doc.

CDS non-device posture

The clinical flag system is designed to qualify as non-device Clinical Decision Support (CDS) under section 520(o)(1)(E) of the FD&C Act. It meets all four statutory criteria; the load-bearing one is independent review — clinicians must be able to review the basis for each recommendation rather than rely on it. CareBridge satisfies this by construction:

• Every flag carries a human-readable rationale.
• Deterministic flags carry a stable rule_id traceable to source code.
• LLM flags record model_id and prompt_version, and are gated by requires_human_review = true.
• Clinicians must enter a reason to dismiss or resolve a flag.
• The patient portal does not surface AI flags.

Auto-acting on flags, surfacing AI diagnostic conclusions to patients, and closed-loop time-critical alerts are explicitly out of scope (they would push CareBridge into device classification). The memo also fixes approved vs. prohibited marketing language. See the CDS exemption memo.

Vendor data handling (Claude API)

Because residual quasi-identifiers survive redaction, outbound LLM prompts are treated as PHI for compliance purposes. A signed Business Associate Agreement (BAA), zero-retention on the API tier, scoped production keys, and model pinning are required before any production PHI traffic reaches the Claude API. Until a BAA is in place, the LLM path is disabled in any environment with real PHI (AI_OVERSIGHT_LLM_ENABLED=false), and deterministic rules continue to fire. See the Anthropic BAA doc.

More compliance and design docs

The source repo’s docs/ directory carries further references: FHIR licensing, image-upload security design, patient-education readability, care-team tables, migration patterns, and the clinician-bridge MVP scope.

See also: AI Oversight Layer, Clinical Domain Model, Design Decisions.