How your patients' records are kept apart, and kept honest.

Every row of clinical data carries the clinic it belongs to, and PostgreSQL row-level security decides what a request may see — not the application. The policies are FORCEd, which means they apply even to the database owner, so there is no privileged path that skips them.

The application never holds a key that can read across clinics. The browser talks to the database with a token scoped to the signed-in person, and the policies derive the clinic from that token. A bug in our code cannot widen it.

A test suite of more than two hundred assertions creates two clinics, signs in as members of each, and attempts to read and write across the boundary in every table. It runs before anything ships.

A consultation, once signed, is frozen by a database trigger. So is an invoice once issued, and a lab report once verified. There is no edit — a correction is a new, dated entry that sits alongside the original.

Stock is not a number that gets incremented. Every receipt, dispense, adjustment and return is a row in an append-only ledger, and the quantity on hand is the sum of that ledger. A discrepancy can therefore be traced to the movement that caused it.

Invoice numbers are issued from a database sequence under a row lock, so they are gapless and never reused, which is what a GST audit expects.

Roles — owner, doctor, receptionist, pharmacist, lab technician — are enforced by the same database policies as tenancy. Hiding a button is a convenience for the user, not a security control; the server refuses regardless.

The last owner of a clinic cannot be removed or demoted, so a clinic can never be left with nobody who can administer it.

Every consequential action writes to an audit trail that no role can modify or delete.

Patient data is stored in Singapore on managed PostgreSQL, encrypted at rest, with automated backups and point-in-time recovery. All traffic is TLS.

Files — logos, uploaded documents, generated PDFs — sit in object storage behind the same per-clinic policies as the database rows that reference them.

PDFs are rendered on the server against a caller’s own token, so a document can only ever be generated from data that caller was already allowed to read.

Card, UPI and net-banking details never reach Clinikr. Payment is handled by Razorpay, and we store only the identifiers needed to reconcile a payment to an invoice.

Subscription state is driven by signed webhooks from the payment provider, verified with a constant-time comparison and deduplicated by event id, so a replayed or forged callback cannot change what you are charged or what you can access.

Export patients, visits, prescriptions, invoices and stock as CSV from inside the app, whenever you like, without asking us. There is a button for it in Settings.

If you stop paying, records stay intact and readable and the export keeps working. Paid modules switch off; nothing is deleted.

Closing your clinic hides it from every screen the same moment you close it, and keeps the records — because retention obligations outlive a subscription. Ask us to erase them and we do, backups included, within thirty days.

Under the DPDP Act a patient may ask what you hold about them, ask you to correct it, or ask you to erase it — and the obligation to answer is the clinic's, not ours. So the tools are in the product: one button produces that patient's entire record as a single file, and the request itself goes into a register with a thirty-day clock on it.

Consent is a dated record rather than a checkbox, kept separately for reminders, promotions and record-sharing. Withdrawing adds a record instead of erasing one, which is what makes it possible to show later that you honoured it.

The clinic states its own retention periods against the statutory minimums, and a breach register sits beside them — because deciding who reports a breach during a breach is too late.