For the IT head
Where your data sits, who can reach it, and what happens when something fails.
Written for technical evaluation rather than procurement theatre. If something here is not specific enough for your assessment, ask and we will answer directly.
Where the data actually lives
- Primary store
- PostgreSQL on a server inside your hospital. Not our cloud.
- Network exposure
- Reachable from the hospital network and explicitly approved devices only. Nothing is published to the open internet by default.
- Cloud sync
- Optional and off unless you enable it. When on, it carries an encrypted delta to your chosen off-site location.
- Internet dependency
- None for core operation. Admissions, dispensing, ordering and billing continue through an outage.
Access control
- Model
- Role-based, with 13 staff roles and 47+ granular permissions.
- Separation of duties
- Clinical and financial visibility are separable — doctors can hold the full clinical record without hospital financials.
- Branch scoping
- Data is scoped per branch, with controlled cross-branch access for users who need it.
- Emergency access
- Break-glass override so clinicians are never blocked. Every use is recorded, attributed and reviewable.
Everything is logged, and the log is yours to watch
- Logins
- Every sign-in and sign-out is recorded with the user, time, device and origin — including failed attempts, so repeated failures against one account are visible rather than buried.
- Record access
- Opening a patient record is an event, not just editing one. Reads and writes are both written to an append-only log: user, action, record, timestamp and origin.
- Prints and exports
- Printing a bill, discharge summary or report is logged, as is any data export. Paper leaving the building is traceable to the person who produced it.
- Activity across the system
- Billing edits, discount approvals, stock movements, order changes and administrative actions all carry an actor and a timestamp.
- Monitored and controlled
- Management can review activity by user, by patient or by date range from inside the platform, and act on what they find — permissions changed or sessions revoked centrally, without waiting on us.
- Authentication
- Short-lived tokens with refresh, and centrally revocable sessions.
- Password policy
- Complexity rules, history to prevent reuse, scheduled expiry and lockout after repeated failures.
Continuity
- Backups
- Scheduled automated backups with restore verification.
- Restore testing
- A backup nobody has restored is not a backup. Restores are verified rather than assumed.
- Data ownership
- The database is yours, in a standard open format, on your hardware. Export does not require our cooperation.
Standards and interoperability
We publish only what we can evidence, and we say plainly which items are still in progress rather than implying more than we hold.
HL7 / FHIR
Interoperability with labs, PACS and external systems.
DPDP Act 2023
Audit trails, access control and data export on demand — built to meet your obligations as data fiduciary.
ABDM / ABHA
ABHA number capture is live. Full health-record linkage is in progress.
NABH documentation
Records, consent and audit trails structured to supply the evidence NABH assessors ask for.
Support, response and continuity
Support hours
Critical issues are covered outside these hours.
Response — critical
Any hour, when clinical work is blocked.
Unplanned downtime
Measured since Feb 2026. Updates deploy 12am–3am IST.
Response targets
These are response times — how long before a person who can help is engaged. We do not publish resolution times, because how long a fix takes depends on the fault and we will not promise a number we cannot control.
- Critical
- Clinical work is blocked — admissions, dispensing, ordering or billing cannot proceed.
- 30 minutes, any hour
- High
- A module or workflow is broken but a workaround exists.
- 2 hours, within support hours
- Normal
- A defect, question or change request that is not holding anyone up.
- Same working day
Updates are deployed between 12am–3am IST, outside clinical hours.
If we disappear tomorrow
This is the question every hospital IT head should ask a vendor of our size, and our answer does not depend on us still being here. The system runs on your server, and your data sits in standard PostgreSQL on your hardware. If we vanished overnight, the installation you have keeps running, and any competent engineer can read the database without our cooperation or our permission.
That is a stronger position than a cloud vendor can offer you at any price — with a SaaS product, your data lives on their servers and their disappearance is your outage.
On top of that, we commit contractually to releasing the source code to you if we cease trading. It is version-controlled and ready to hand over — so the worst case is that you hire another engineer, not that you replace the system.
Want this as a document for your evaluation file?
Request the technical pack