PlatformPatient JourneySelf-HostedSecurityAboutContact Book a demo

Security & data control

Security Designed Around Hospital-Controlled Data

Every hospital system claims to be secure. The claim is worth nothing without the specifics, so this page states what auraCare actually does and how each control can be checked in a deployment rather than taken on trust.

The single largest control is architectural: your patient records are not in our database, because there is no shared database to be in.

Book a demo Talk through your workflow
The first control

Isolation before any other control.

Most security questions change shape once the data is not pooled. These are properties of the deployment model rather than features that can be switched off.

  • Each hospital runs an isolated instance. There is no shared multi-tenant patient database and no pooling of records across hospitals.
  • The database runs in your environment, in a region you choose, under credentials you hold.
  • We hold no copy of your patient records and have no standing access to your deployment.
  • A security incident affecting another hospital’s deployment is not an incident affecting yours, because they share no infrastructure.
  • The public website at auracare.cc holds no patient data at all — it is a static publication with no login and no database.

Controls inside the application.

These are implemented today and can be inspected in a deployment rather than taken on trust.

CredentialsPasswords are stored as scrypt hashes with a per-user random salt, and verified with a constant-time comparison so a wrong answer takes as long as a right one.
Data isolationPostgreSQL row-level security policies scope tenant-owned tables to the organisation context set on each transaction, enforced by the database rather than only by application code.
Role-based accessUsers act through roles and permissions, so what a receptionist can reach is not what a clinician or an administrator can reach.
Audit trailRecord access, clinical changes, administrative actions and consent-related events are written to an append-oriented audit table, indexed by visit so a question about one patient has one answer.
BackupsScheduled database dumps in PostgreSQL’s custom format with a retention window — the reference deployment takes one daily and keeps fourteen days — written into your environment.
TransportTraffic to the staff, patient and display surfaces is served over TLS.
The access we do not hold

What happens when we need to look at something.

Vendor support is where hospital software security is usually quietly undone. A permanent administrative account for the vendor, shared among its engineers, is convenient and almost impossible to justify to a regulator.

auraCare has no standing access to a deployment. When support, implementation, migration or fault diagnosis requires it, the hospital grants access.

That access is limited to what the task requires, time-bound so far as practicable, and recorded in the same audit trail as any other activity — so the hospital can see afterwards exactly what was done and when.

Information a hospital sends us in a support request — a screenshot, an export, a log extract — is used only to handle that request and deleted when it is no longer needed for it.

Questions worth asking any hospital vendor.

Where exactly do our patient records live?

In a PostgreSQL database inside the environment you chose, in the region you chose, under credentials you hold. Not in a database we operate, and not alongside another hospital’s records. This is the answer we would want from a vendor, and it is worth asking every vendor you evaluate — a great many cannot give it.

Who at auraCare can read our data?

Nobody, until you grant access for a specific task. There is no permanent vendor account and no standing administrative access to a deployment. When access is granted it is scoped to the task, time-bound so far as practicable, and appears in your audit trail alongside every other action, so you can review it afterwards rather than take our word for it.

Is auraCare compliant with the DPDP Act and ABDM?

The software is built to support the obligations those frameworks place on a hospital, and the privacy policy sets out the handling in detail. But compliance is a property of your deployment and your practices as much as of the software, and no regulator has assessed auraCare. ABDM registration is under application and no ABDM functionality is available today. Treat any vendor claiming to make you compliant by installation with suspicion.

Send us your security questionnaire.

If your hospital has a security or procurement questionnaire, send it. We would rather answer it precisely — including the questions where the answer is "not yet" — than have you infer capability from a brochure.

Security questions can be raised with us directly at [email protected].

Book a demo Talk through your workflow

Answers that are "not yet" will be given as "not yet".