Security and compliance
Built for the review it will be put through.
Clinical software is chosen by a department and approved by everybody else. Where a control is enforced by the database rather than by application code, we say so — that is the difference between a policy and a guarantee.
Data at rest
Encrypted, and still searchable.
- AES-256-GCM on name, medical record number, date of birth, gender and hospital identifiers
- Partial-name search runs against a keyed hash index, never readable data
- Privacy request details and second-factor secrets encrypted the same way
- Production refuses to start without real keys, or with demonstration accounts present
Audit trail
Append-only, enforced by the database.
- The audit table rejects updates and deletes outright
- Actor, the role they held, entity, location, address and request identifier
- Changes recorded as a field-level diff, not an opaque note
- Identifying fields stripped from audit payloads before storage
- Org-scoped, filterable, exportable to CSV
On the device
Offline charting without leaving a readable copy behind.
Working offline means holding clinical data on a shared ward device. That is a real exposure, handled explicitly rather than assumed away.
Keyed to the person
One data key, never written down in the clear, wrapped by a key derived from the user's password. Possession of the device is not possession of the data.
Separated per user
Each user gets their own local store, so two clinicians never share a cache and signing out clears only that user's data.
Relocks on idle
A convenience unlock covers the idle window then expires. Tightening the organisation's timeout tightens local exposure with it.
Bounded and revocable
Offline access is granted per user and device for a bounded period and can be revoked centrally — without discarding unsynchronised writes.
Metadata treated as data
Local index columns are stored as keyed tokens, and error messages kept on the device are stripped of identifiers.
Wipe on command
An administrator can force every device in an organisation to discard its copy and re-download — including devices offline at the time.
Concurrent edits
Two nurses, one sheet, no lost hours.
In most synchronising systems the last writer wins. In a clinical chart that quietly destroys the other person's work, and nobody finds out.
Merged
Flowsheet hours edited independently are combined by hour, after unit conversion. Both sets survive.
Surfaced
A real conflict is shown side by side, field by field, and the clinician chooses. The decision is recorded.
Replayable
Every offline write sits in a durable server-side ledger, so retries are idempotent and failures can be examined.
Access and identity
- Roles — clinician, nurse, researcher, administrator, super administrator
- Hierarchy — organisation, centre, location, department, intensive care unit
- Isolation — one organisation per user, enforced by database trigger
- Masking — out-of-scope records reported as not found, not forbidden
- Sign-in — password or phone code, with optional enforced second factor
- Sessions — idle timeout, rotating hashed refresh tokens, expiring trusted devices
- Leavers — deactivation revokes access but preserves record authorship
Data rights and retention
- Jurisdictions — India DPDP, EU and UK GDPR, and United States requirements
- Thirteen request types — access, correction, erasure, portability, grievance and more
- Statutory clock — a due date set on every request at intake
- Triage — scoped to the organisation the request concerns
- Retention — separate periods for records, audit, notifications and requests
- Deletion — destructive patient deletion gated to the highest privilege
Deployment
One container, one server, inside the hospital.
Database, application, web layer and interface ship as a single image. No cluster to run, and no external dependency required for clinical use.
On premises or hosted
The same software either way. Moving between them is a data migration, not a different product.
Works through outages
Installs as an application on ward devices and keeps charting when the network drops.
Configured per organisation
Units, validation ranges, autosave, session policy, second-factor policy, retention, theme and logo.
Four languages
English, German, Telugu and Marathi, translated through the clinical forms themselves.
Notifications the unit controls
In-application, email, SMS and WhatsApp, with per-user opt-out and a queue that retries rather than dropping. Every rule ships disabled.
Data in and out
Patients import from CSV with per-row validation. Entry tables and the audit trail export to CSV. Every record prints.
Engineering practice
- Secret, container, image and infrastructure scanning in the build
- A critical finding fails the build rather than filing a ticket
- Append-only audit, single-org, version stamping — all enforced in the database
- A user who authored clinical records cannot be deleted
- Timezone handling treated as a clinical safety issue, and documented
What we do not claim
We hold no third-party security or medical-device certification today. The controls here are real and can be demonstrated, but they have not been externally audited, and we will not imply otherwise.
There is no HL7, FHIR or electronic medical record integration, and no direct feed from dialysis machines. Data moves in and out by CSV and by print.
The software supports documentation and review. It does not replace independent clinical judgement, local protocols, or the hospital's own obligations for the medical record.
For reviewers