Security Overview
The controls ClinicalHIS runs today — verified in the platform, no aspirational claims.
Last updated: 17 October 2026
This page describes only controls that verifiably exist in the deployed platform. Where a common control is absent, we list it under “Known limitations” rather than implying it.
Transport security
HTTPS enforced for all sites and APIs (TLS 1.2/1.3, forward-secret cipher suites) with HSTS max-age one year, includeSubDomains and preload. HTTP requests are redirected. Certificates are issued and rotated via Let's Encrypt.
Authentication
Password hashing (bcrypt); account lockout with escalating lockout times after repeated failures; login rate limiting. Self-hosted multi-factor authentication: TOTP authenticator apps, WebAuthn passkeys, single-use backup codes. MFA is enforceable per hospital and enforced by policy for sensitive roles; sensitive account operations (password change, MFA changes, credential deletion) require step-up re-authentication.
Authorisation and isolation
Role-based access control with per-role permission sets, per-tenant permission restrictions, and tenant scoping enforced on every API query. Administrators can see and manage exactly their own hospital's data. Sessions expire when idle (default 15 minutes) and tokens can be revoked server-side; refresh tokens rotate and are stored in HttpOnly cookies.
Audit and monitoring
Append-only audit logs (UPDATE and DELETE are rejected by database triggers) with per-row SHA-256 checksums and integrity-verification functions; login history with IP and device; PHI-access logging. Audit-log archival functions exist with restricted access. Administrative and operational logs are stored locally and are not exported off the platform.
Encryption
In transit: TLS 1.2/1.3 everywhere. At the field level: AES-256-GCM for MFA secrets and integration credentials. At rest at infrastructure level: not yet — hosting disks are not full-disk encrypted. We disclose this rather than claim it; tenant-local hosting keeps data on your own hardware if your risk assessment requires it.
Backups and recovery
The hosting server takes regular local database backups with a rotation policy, and the deployment is containerised so the stack can be rebuilt quickly. Honest limitation: backups currently remain on the same physical server — they are not replicated off-site, and restore drills are operational practice rather than a contractual commitment.
Platform hardening
Security headers (X-Frame-Options DENY, nosniff, XSS protection) and strict robots/noindex boundaries for private areas; input validation and parameterised queries throughout; API rate limiting on authentication endpoints; container-level service isolation on an internal network; secrets held outside the codebase; dependency updates tracked.
Vulnerability disclosure
Found something? Email security@clinicalhis.com. We take reports seriously, will acknowledge receipt, and will keep you informed of remediation. Please do not test against tenant data or degrade service.
Known limitations
Stated plainly so you can assess us honestly: no full-disk encryption at rest; backups are local, not off-site; no third-party certifications (SOC 2 / ISO 27001); no 24/7 staffed security operations centre; no published penetration-test report (assessments to date are internal). None of these are hidden in fine print — this page is the fine print.
Questions: security@clinicalhis.com · Claridad Health Solutions, P.O. Box CT 4835, Cantonments, Accra, Ghana.