Security
Security your governance team can check.
How Aksh protects clinical data, who can see it, and what has to be true before an organisation goes live. We do not claim certifications we do not hold.
01
Access control
Who can see what is decided in the database, not only in the interface.
Row-level securityEvery query from the application runs as a restricted database role scoped to the signed-in user’s organisations. A clinic cannot read another clinic’s patients, even through a faulty screen.
Patients see only themselvesA patient account is bound to one record, confirmed with an invite code and date of birth. Sharing with other organisations needs the patient’s recorded consent.
RolesClinical worklists are limited to clinicians. Organisation settings, invites and go-live are limited to organisation admins. Aksh reviewers act only on go-live.
Registration checksA clinician’s professional registration is checked and recorded before their organisation can go live.
02
Authentication
Accounts are protected against guessing and stolen passwords.
Two-step sign-inTime-based codes from an authenticator app, each usable once, with single-use recovery codes. Secrets are encrypted at rest. Required for Aksh reviewers.
PasswordsStored only as salted hashes. Never logged, never shown, never sent by email.
Rate limitsSign-in, sign-up and password reset are limited per address and per network, backed by the database so limits hold across servers.
SessionsSigned, HTTP-only cookies over TLS. Privileged pages refuse sessions that did not pass two-step sign-in.
03
Audit and integrity
The record of what happened cannot be rewritten.
Append-only historySlot actions, consent decisions, go-live evidence, registration checks, CGM uploads and weekly sign-offs are append-only: the database rejects edits and deletions.
AttributionEvery action records who took it, in which organisation and environment, and when.
Honest measurementResults use one published definition and a baseline locked before go-live. A booking counts only after it is read back from your schedule.
04
Data protection
Your organisation stays in control of its data.
EncryptionTLS for all traffic with HSTS. Data encrypted at rest by the database service. Two-step secrets additionally encrypted by Aksh.
No patient data to AI modelsIn production, no patient data is sent to an AI model, and the services that could do so are switched off. Ranking and metrics are fixed rules you can read. AI features are tested on synthetic data and reach real patients only through an approved go-live.
ExportOrganisation admins export everything their organisation holds as one machine-readable file; patients download their own record. Exports are audited.
RetentionOperational error logs are kept for 90 days and are scrubbed of personal details; rate-limit counters for 24 hours.
Separate environmentsProduction holds real organisations only. Testing runs on a separate database with synthetic data; tooling refuses to write test data to production.
05
Operations
How the service is run and watched.
Backups and restoreThe production database is backed up by the database service with point-in-time restore. A recorded restore test is part of readiness before the first clinic goes live.
MonitoringServer errors are recorded and alert the operations team. An independent check confirms every 15 minutes that the service and database are up. Scheduled jobs expire stale offers and apply retention daily.
Secure defaultsStrict transport security, no framing, no content sniffing, and a restrictive permissions policy on every response.
ChangesPinned dependency versions, reviewed security advisories, and the full automated test suite on every change before it reaches production.
06
Clinical safety
Aksh supports staff. It does not act on patients.
People decideAksh ranks and drafts. It never contacts patients, books appointments, diagnoses or recommends treatment.
Go-live governanceLive use needs a data processing agreement, a privacy impact assessment with acceptable residual risk, a named clinical safety lead, an agreed contact channel and a locked baseline, each reviewed by Aksh.
Shadow modeOrganisations start in shadow mode: staff make every contact through their own channels, and Aksh keeps the record.
Missing data is shownPatients who cannot be offered a slot are listed with the reason, and incomplete CGM data is labelled, never silently dropped.
Reporting a vulnerability, or need our security documentation for a procurement review? Email gnaneshwer.jadav@gmail.com.
Questions from your data protection lead?
We will share our data processing agreement and help with your privacy impact assessment.