CRIE
Sign in

Compliance posture

CRIE is engineered to align with HIPAA Security Rule expectations and GDPR principles for health-data processors. Final certification is the responsibility of the deploying entity, but the platform is designed to make that path short.

HIPAA Security Rule alignment

  • Access controls — unique user IDs, RBAC, automatic logoff via session expiry, emergency-access role available.
  • Audit controls — append-only, hash-chained audit_log on every PHI touch.
  • Integrity — pgcrypto envelope encryption + DB-level checksums + hash chain on audit records.
  • Person/entity authentication — Argon2id passwords, PASETO sessions, optional MFA hook.
  • Transmission security — TLS 1.3 enforced, HSTS on, strict CSP with nonces.

GDPR considerations

  • Lawful basis — clinical necessity (Art. 9(2)(h)).
  • Data minimisation — only fields needed for the analysis are persisted; logs use opaque IDs.
  • Right to erasure — soft delete via deleted_at with a scheduled hard-purge job.
  • Data portability — patient records exportable as structured JSON.

ISO 27001 controls in scope

  • A.5 Information security policies — see docs/policies/.
  • A.8 Asset management — repo structure + Coolify inventory.
  • A.9 Access control — RBAC + RLS + secret hygiene.
  • A.12 Operations security — change management via PR + CI gates.
  • A.14 System acquisition — SBOM via cargo-deny + pnpm audit.

Operational controls

  • gitleaks runs on every CI build — secrets in diffs fail the pipeline.
  • cargo-deny enforces license + known-vulnerability policies for Rust dependencies.
  • PR template requires a Threat-model impact and PHI impact declaration before merge.