Where your clinic's data lives, and what we do with it

Patient records, prescriptions and invoices are stored in a Postgres database hosted in Mumbai. The application server runs in Mumbai too, in Google Cloud Run's asia south 1 region, which is named in the deployment script in our source. Nothing about a clinic's day needs to leave the country to be processed.

Files a clinic uploads, meaning scans, lab reports and photographed paperwork, are held in that same database rather than in a separate file store, so they sit in Mumbai beside the record they belong to. A file is served only after the request has been authorised.

Passwords are stored as argon2id hashes. The plain password is never written down anywhere, which also means nobody here can tell you what yours is, only reset it.

A session cookie holds an opaque token, and the database stores only the SHA 256 of that token, never the token itself. The practical consequence is the one that matters: a stolen copy of the database does not hand anybody a working session.

Repeated wrong passwords lock the account for a period that grows with each further attempt, and the lock survives a server restart because it is a column in the database rather than a counter in memory. The patient portal PIN uses the same ladder.

Staff and patients are two separate populations with two separate cookies and two separate session tables. A patient session presented to a staff screen is not a weaker session, it is no session at all, because the two are validated by different code against different tables.

Opening one named patient record is itself recorded, with who opened it and when. Searches and list views are deliberately not recorded: a log with a row for every keystroke is a log nobody reads, and we would rather the record of who read a file be short enough to actually review.

The log is append only, and that is enforced by the database rather than by our own code being careful. A trigger refuses every attempt to update or delete a row in it, including attempts by the application's own connection, which owns the table. There is one documented exemption and it exists so the demo clinic can be rebuilt.

Every query that touches clinic data filters on the clinic the signed in person belongs to, and the clinic is taken from the session rather than from anything the browser sends, so a caller cannot ask for another clinic's data by changing an identifier in a URL.

The honest description of how that is held: it is written into each query and covered by tests, not enforced by a database level rule that would make a mistake impossible. A vendor telling you their isolation is absolute is either using row level security, in which case ask them to show you, or overstating it.

Being straight about this one, because this page said the opposite until today: the product does not currently record patient consent. The record has a place to keep it and the registration screen does not ask, so obtaining consent and keeping proof of it is your clinic's job at the moment, not something the software does for you. We would rather correct that here than let you rely on it.

Your records are yours. Patients, visits, billing and expenses all export to CSV from inside the product, and there is a monthly workbook built for your accountant. Leaving is not a support ticket and there is no charge for it.

• No certification of any kind, and no compliance badge.
• No claim about any statute, rule or required retention period.
• No penetration test has been commissioned yet.
• No published customer references, because we are new.

If any of that is a blocker for your clinic, say so on a call and we will tell you where it stands rather than sending a brochure.