Security built for health data
Health data carries a duty of care. This page describes the controls as they are actually built: what protects patient data in transit, at rest, in the audit trail, and inside AI features. Where something is still in progress, we say so.
Who gets in, and what they can reach
Strong defaults at the door, and permission checks that follow you past it.
Encrypted in transit and at rest
All traffic between your browser and the platform is encrypted with TLS 1.3. Data at rest is encrypted with AES-256.
Two-factor authentication on every login
Every login requires a second factor delivered by email. A device can be trusted for up to 30 days, after which it must verify again.
Short-lived, rotating sessions
Access tokens expire after 30 minutes and refresh tokens rotate on a 7 day cycle. Both are delivered as httpOnly cookies, out of reach of scripts running in the browser.
Role-based access with ownership checks
Every API endpoint enforces role-based permissions, and any request touching a patient record must also prove the record belongs to that user or their care team. This is verified by an automated authorization test that covers routes and controllers alike.
Every access is on the record
Access to a patient record leaves a permanent, verifiable trace, and the patient can read it.
A tamper-evident access log
Every read of patient health information is recorded in a hash-chained access log. Each entry commits to the one before it, so altering or deleting history breaks the chain and becomes detectable. The chain can be verified end to end on demand.
Patients can see who looked
Patients can view the full access history of their own record, including denied attempts. Denials matter: they are how a patient discovers someone probing a file they were not allowed to open.
Data handled with an exit in mind
From the first record to the right to be forgotten, with research exports that put safety before convenience.
Right to erasure that actually completes
Erasure derives its deletion set from the live foreign-key graph of the database, so every linked record is found, including tables added by future changes. Each erasure produces a certificate, and the erasure event itself is written to the audit log as proof it happened.
Research exports that refuse to guess
Research exports are k-anonymised with k of at least 5, suppressing rows that would identify individuals. When the safety check cannot see the identifying columns in a dataset, it refuses to release it rather than certify a safety it never verified.
De-identification that cannot be joined
Pseudonyms use a keyed hash with a fresh salt for every export, so two releases can never be linked on the pseudonym. Columns are exported from an allowlist: anything unclassified is dropped, not leaked.
Retention that cannot touch the audit trail
Administrators can configure retention and deletion policies, but no policy can delete or rewrite the access log. The evidence of who accessed what sits deliberately outside the reach of scheduled deletion.
Decision support, never the decision
AI in ICOPE Connect assists the clinician. It never replaces them, and it never learns who the patient is.
Decision support, clearly labelled
Every AI output in the platform is labelled as decision support. The clinician always makes the final clinical decision, and AI recommendations are traceable to the underlying assessment data.
Patient identity stays out of AI prompts
A prompt-privacy gate keeps patient identity out of every prompt sent to an AI model. The gate is enforced by automated checks that discover every prompt builder in the codebase, so a newly added AI feature is covered the moment it is written.
Data residency enforced at startup
In production, the platform refuses to start with AI features enabled unless a zero-retention agreement is attested or an in-region AI endpoint is configured. Data residency is a boot requirement, not a policy document.
Where we stand, honestly
ICOPE Connect is built to align with the Mauritius Data Protection Act 2017, which governs how personal and health data may be processed in Mauritius. The controls on this page, from the tamper-evident access log to the right to erasure, exist because the Act requires them and because patients deserve them.
A Data Protection Impact Assessment for the platform has been drafted. Registration with the Data Protection Office, including the appointment of a named Data Protection Officer, is in progress and will be completed before the platform processes patient data in production. We would rather tell you what is still in progress than imply it is done.
If your procurement process needs more detail, a security questionnaire completed, or a conversation with the team about architecture and data residency, ask us. We answer these questions directly.
Questions about security?
Architecture, data residency, DPA alignment, or a vendor security questionnaire: send it over and we will answer it properly.