Security & Compliance

Cari implements technical safeguards required by the Health Insurance Portability and Accountability Act (HIPAA) for protecting electronic Protected Health Information (ePHI).

Access Control (164.312(a))

• Unique user identification: Every user has a UUID-based account. All API requests are tied to authenticated user identities via PASETO tokens containing the user's sub (subject) claim.
• Emergency access procedure: Super Admin accounts can access any patient record in emergency situations. All emergency access is logged in the audit trail.
• Automatic logoff: Access tokens have short expiration times. Refresh tokens enable seamless re-authentication without storing long-lived credentials.
• Encryption: All data is encrypted in transit (TLS 1.3) and at rest (CockroachDB encryption at rest).

Audit Controls (164.312(b))

• Clinical audit events: The Session service provides a full audit event system at /api/clinical/audit that records creation, reads, updates, and deletions of clinical records.
• Per-record audit trails: Every clinical record has a dedicated audit trail accessible at /api/clinical-records/:id/audit.
• User activity trails: All actions by a specific user can be retrieved via /api/clinical/audit/user/:user_id.
• Search and filtering: Audit events can be searched by resource type, user, date range, and action type at /api/clinical/audit/search.

Person or Entity Authentication (164.312(d))

• Multi-factor authentication: TOTP-based MFA is available via /api/auth/mfa/enroll. The implementation follows NIST SP 800-63B AAL2 guidelines.
• PASETO v4 tokens: Cryptographically signed tokens that cannot be tampered with. Unlike JWT, PASETO eliminates algorithm confusion attacks by design.
• Token refresh flow: Short-lived access tokens with secure refresh mechanism prevent long-term credential exposure.

Transmission Security (164.312(e))

• All API traffic is encrypted with TLS 1.2+ (Cloud Run enforces HTTPS)
• Internal service-to-service communication runs within Google Cloud's private network
• CORS policies restrict browser access to approved origins

Cari implements the rights granted to data subjects under the EU General Data Protection Regulation (GDPR) through dedicated API endpoints in the Patients service.

Right to Erasure (Article 17)

Patients can request complete deletion of their personal data. Erasure requests are submitted and tracked through a formal workflow:

// Submit an erasure request
POST /api/patients/:id/erasure-request
Authorization: Bearer v4.public.eyJ...
Content-Type: application/json

{
  "reason": "I no longer wish to use the platform",
  "confirm": true
}

// List all data subject requests for a patient
GET /api/patients/:id/dsr
Authorization: Bearer v4.public.eyJ...

Right to Data Portability (Article 20)

Patients can export their complete health record in a machine-readable format:

// Export all patient data
GET /api/patients/:id/export
Authorization: Bearer v4.public.eyJ...

// Returns structured JSON with all clinical records,
// prescriptions, lab results, appointments, and demographics

Consent Management

Cari implements granular consent management that tracks what data a patient has consented to share and with whom. Consent can be granted, requested, approved, and revoked:

The session recording system has its own consent layer at /api/sessions/consents to manage consent for clinical session recording and AI transcription.

Cari's security architecture aligns with ISO 27001 information security management controls:

Cari enforces RBAC at two levels: the API gateway and individual service middleware. The gateway checks roles before proxying requests to downstream services, and services apply additional role checks via shared middleware from cari-core.

Role Hierarchy

RBAC Middleware Functions

Services use these shared middleware functions from cari-core:

Gateway-Level Role Enforcement

The gateway applies path-based role requirements before proxying requests:

Cari maintains comprehensive audit logs for clinical data access and modifications. The audit system captures:

Audit API

// Log a clinical audit event
POST /api/clinical/audit
Authorization: Bearer v4.public.eyJ...
Content-Type: application/json

{
  "resource_type": "ClinicalRecord",
  "resource_id": "record-uuid",
  "action": "read",
  "metadata": { "reason": "Patient consultation" }
}

// Get audit trail for a specific resource
GET /api/clinical/audit/resource/ClinicalRecord/{resource_id}

// Get all audit events for a user
GET /api/clinical/audit/user/{user_id}

// Search audit events
GET /api/clinical/audit/search?action=update&from=2026-04-01&to=2026-04-18

Failed asynchronous events (e.g., user creation notifications, organization member added events) are captured in a Dead Letter Queue (DLQ) to prevent silent data loss. Administrators can review, retry, or discard failed events: