How the platform is built
Healix is a multi-tenant hospital management system. Each customer runs in its own instance with its own database and file store; there is no shared patient table between facilities. Within an instance, every request is checked for tenant membership, and every sensitive action is checked against the permissions granted to the user’s role.
Access control
- Role-based permissions are evaluated server-side on every route and action, not only in the interface. Permissions are seeded by database migration and granted to roles by an administrator — a new permission is never granted automatically.
- Multi-factor authentication (TOTP with backup codes) is available to every user and enforced for administrative roles. An administrator can extend enforcement to further roles.
- Session controls: sessions are regenerated at sign-in, idle sessions expire, and an expiring session is warned before it ends so that unsaved clinical work is not lost.
- Single sign-on through OpenID Connect is supported for organisations that manage identities centrally. SAML is not supported; where an identity provider offers only SAML, OIDC or an OIDC bridge is required.
Protecting the data
- Encryption in transit: every connection to the platform is served over TLS with a certificate from a public certificate authority.
- Field-level encryption at rest: identifying patient fields (national and passport numbers, contact details and similar identifiers) are encrypted in the application before they reach the database, with keys held outside it.
- Audit trail: access to and changes of patient records are written to an append-only audit log that is hash-chained — each entry carries the hash of the entry before it, so a removed or altered entry is detectable.
- Privacy controls: patient exports are gated by a dedicated permission and are themselves audited; a data-subject access export produces an individual’s record in a portable format; erasure removes identifying details while preserving the clinical and financial records that law requires a facility to keep.
- Retention: retention periods are configured per facility inside the system rather than hardcoded, so a facility can apply the rules of its own jurisdiction.
Operating the service
- Change management: every change is developed and verified in an isolated staging environment before it reaches production. Production code is deployed from a tagged release, not edited in place.
- Backups: a full database backup is taken before every deployment and retained in rotation. Restores are exercised, not assumed.
- Monitoring: application and access logs are reviewed for errors and for signs of abuse; a failing integration surfaces an alert rather than failing silently.
- Vendor management: every third party that processes personal data on our behalf is listed in the sub-processor register and bound by written data-protection terms.
- Artificial intelligence: AI features are opt-in per facility and per feature. Their output is decision support only and never changes a record without a clinician accepting it. Prompts and responses are logged for audit, and patient data is not used to train models.
Incident response
If we become aware of a security incident affecting customer data, we contain it, assess its scope and notify the affected controllers without undue delay, with the information they need to meet their own notification duties. Our Data Processing Agreement sets out that commitment in clause 8.
What we do not claim
Healix is not currently certified to ISO/IEC 27001 or SOC 2, and we do not hold an HDS (Hébergeur de Données de Santé) certification. Our controls are described above so that you can assess them directly; the certification programmes are planned, and this page will say so when a certificate has been issued and can be verified — not before.
No independent penetration test has been completed yet. We test security during development and review the platform continuously, but a third-party penetration test and a published summary of its findings are still outstanding.
Where a facility needs a specific regulatory qualification of the software itself — for example medical-device classification — that assessment is the facility’s to make with its own adviser. We will answer technical questions and provide the documentation needed for it.
Reporting a vulnerability
If you believe you have found a security weakness in Healix, please tell us before disclosing it publicly. Write to support@healix.co.ke with enough detail to reproduce the issue. We acknowledge reports promptly, keep you informed while we investigate, and will not pursue legal action against a researcher who acts in good faith, avoids privacy violations and does not disrupt the service.
Questions
Security questionnaires, architecture questions and due-diligence requests can be sent to support@healix.co.ke. We answer in writing.
Questions about this document? Write to support@healix.co.ke and our team will answer in writing.