Privacy

Two different relationships sit inside one product, and under India's Digital Personal Data Protection Act they carry different duties.

For patient records, the clinic decides and we process. Your clinic is the Data Fiduciary. It decides what to record about a patient, who on its staff may see it, how long to keep treating that person, and what to tell them. We are its Data Processor: we hold the records, run the software over them, and act on the clinic's instructions. We do not use a clinic's patient data for our own purposes, we do not sell it, and we do not use it to market anything.

For your own account and your enquiry, we decide. Staff sign in details, and the details you type into the demo form on this site, are ours to answer for. We are the Data Fiduciary there.

The practical consequence is worth stating plainly: if you are a patient and you want your record changed or removed, the clinic that treated you is who decides, and we act on what they ask. We cannot overrule them about their own records.

About a patient, because the clinic recorded it: name, mobile number and whose number it is, gender, age, an optional date of birth, a file number, allergies, long running conditions, a prior history note, guardian name and relation for a minor, address and who referred them. Then the record of care itself: visits, vital signs, the complaint, diagnoses, prescriptions and their earlier versions, notes added after a visit closed, procedures, pharmacy purchases, invoices and payments, follow up reminders, and any file the clinic or the patient uploaded, such as a photographed lab report.

About a member of clinic staff: name, mobile number, an email address if given, a user name, and a password stored only as a hash. Each sign in session also records the address the request came from and the browser it came from.

About someone who fills in the demo form: name, mobile number, clinic name and city. Nothing else. That is the whole record, and one phone number is one row, so filling the form again updates it rather than adding another.

About how the software is used: a usage record for each action, holding which action, which screen, which clinic, which role, whether it succeeded, and how long it took. These carry no free text. Five of them can carry a patient identifier, all of them ordinary successes such as printing a document or opening a file, and every other kind has that field emptied before it is written.

Everything a clinic records lives in one managed PostgreSQL database hosted in Mumbai, in AWS ap south 1, run for us by Supabase. The application server runs in Mumbai too, in Google Cloud Run's asia south 1 region.

Uploaded files, meaning scans, lab reports and photographed paperwork, are stored inside that same database rather than in a separate file store. The product can be configured to use object storage instead and that is not switched on, so today a patient's files sit in Mumbai beside the rest of their record.

The website you are reading is served by Vercel. We have not pinned it to an Indian region, so pages of this marketing site may be served from outside India. No clinic data is involved in serving it.

The companies that hold or process data on our behalf:

• Supabase and AWS, for the database in Mumbai.
• Google Cloud, for the application server in Mumbai.
• Vercel, for this website.
• Anthropic, and only when your clinic has switched an AI feature on. Both AI settings are off unless somebody asks for them.
• Meta, for visitors to this marketing site only, if the advertising pixel is active. It never runs inside the clinic app.

We do not sell data to anybody, and there is no advertising network, no data broker and no analytics company in the list above. There is no SMS or WhatsApp provider either: when your front desk sends a follow up over WhatsApp, the link opens WhatsApp on their own phone or computer and the message goes from them, not through us.

This section is more specific than most, because a general sentence about AI would hide the thing that actually matters, which is that the different AI features send different amounts of a patient's record.

Prescription drafting and letter drafting send a short context built to exclude identity: age, gender, long running conditions, and up to two recent diagnoses. They also send what the doctor typed, and the pre visit note if the patient wrote one, as free text. That free text is not filtered, so if somebody types a name into it, the name goes.

The assistant is different, and you should assume it sends identified data. When a doctor or a member of staff asks it to look something up, it runs the same lookups the screens do and sends the answers back to the model, which for a patient search or a patient history means names, mobile numbers and clinical detail.

The pharmacy features that read a supplier's bill or price list send that document, which is commercial information and not patient data.

We record what each model call cost and how many tokens it used. We do not store the text sent to the model or the text it sent back.

Clinical and financial records are kept, and we do not delete them. There is no expiry, no automatic clear out, and no job anywhere in the product that removes or anonymises a patient record. If you have read that medical records should be disposed of after some number of years, that is a decision for your clinic and it is not something this software does on its own today.

Deleting inside the product hides rather than erases. When a clinic removes a patient file, a visit or an uploaded document, the row is flagged as removed and stops appearing anywhere. The content stays in the database. Ask us if you need something genuinely destroyed and we will do it by hand.

Usage records are deleted after ninety days. A sweep runs automatically, rolls each day up into counts, and then deletes the individual records. The counts that survive carry no patient, no person and no session, only totals and timings, and those we keep.

Demo enquiries stay until we remove them, which we do on request and periodically anyway.

The audit trail cannot be edited or deleted, including by us. The database refuses it. That is deliberate, it is what makes the trail worth having, and it has a consequence you should know: if a record was read or changed, the fact of it stays recorded even after the record itself is removed.

If you are a clinic, your data is yours and it is already in your hands. Patients, visits, billing and expenses export to CSV from inside the product, and there is a monthly workbook for your accountant. It costs nothing and you do not need us to run it.

If you are a patient, start with the clinic that treated you. They hold the record and they decide. The patient portal, where a clinic has it switched on, lets you see your own visits, prescriptions and bills, and upload a report. It does not let you export everything, correct anything or delete anything, so those requests are handled by people rather than by a button: ask your clinic, or write to us and we will work with them. We will answer, and we will tell you plainly if the answer is that the clinic has to decide.

There is also no screen today that shows you who opened your record. The trail exists and is protected. Reading it back is something you have to ask for.

A portal account is a phone number, not a person.Anyone who signs in with that number and its PIN sees the records of every patient registered under it, at every clinic using the portal. That is deliberate, because it is how a parent sees a child's visits and how one phone serves a household. It also means that if a number is shared, or reused for somebody new, the records travel with the number. There is no separate consent step for each person inside a household.

A patient session and a staff session are different things. They use separate cookies and separate tables, so a portal sign in can never reach a staff screen, whatever it is presented to.

Passwords and portal PINs are stored as argon2id hashes, so nobody here can tell you what yours is, only reset it. A session cookie holds an opaque token and the database stores only a hash of it, which means a stolen copy of the database hands out no working sessions. Repeated wrong attempts lock an account for a period that grows each time, and the lock survives a restart. Traffic is over HTTPS.

Inside a clinic, what each person can reach is decided by their role rather than by which screen they found: the front desk cannot open clinical history, a doctor cannot total the clinic's takings, and a waiting room display can read token numbers and nothing else.

An honest note on isolation between clinics, the same one our security page makes: it is enforced by a filter applied to every query and covered by tests, not by a database level rule that would make a mistake impossible.

The clinic app sets one cookie to keep you signed in, and the patient portal sets its own. Both are strictly necessary: without them there is no way to stay signed in. Neither is used for advertising.

This marketing site may run a Meta advertising pixel, which sets Meta's own cookies and tells Meta that a browser visited a page here. There is no consent banner today, and if you would rather it did not run, a tracking blocker or your browser's own controls will stop it.

If this page changes in a way that matters, we will change the date at the top and tell clinics that are using the product. For anything here, including a request about your own data or somebody else's record, write to or call +91 76969 98019. Abhishek Dogra answers these personally, and is the person to contact if you are unhappy with how a request was handled.

The companion page is our terms, which covers what you are buying and what happens if you stop paying.