← mydosha.org

How we protect your patients' data

MyDosha handles special-category health data on behalf of Ayurvedic practitioners. We treat that as a responsibility, not a checkbox. This page sets out — in plain language — where your data lives, who can reach it, and what happens if something goes wrong.

Where your data lives

All practitioner and patient records are stored in the European Union, in a managed PostgreSQL database (Supabase, AWS eu-central-1, Frankfurt). MyDosha is operated from the EU; the operating entity is European. We do not sell data, and we do not show advertising. We do not process the Dutch BSN or any other national identification number.

Who can reach the data

• Two-factor sign-in. The practitioner portal is protected by a password plus a one-time email code. Codes expire quickly and lock out after repeated wrong attempts.
• Per-clinic isolation. Each clinic's records are partitioned by a clinic identifier and every data request is scoped to the signed-in clinic. One clinic cannot read or write another's patients, appointments, messages, documents, invoices, or AI-assistant context. This isolation is covered by automated regression tests and a static check that run on every change.
• Least privilege. Database credentials never reach the browser. The front end talks only to our API, which enforces access on the server side.
• Audit trail. Security-relevant actions are written to an append-only audit log.
• Patient access. Patients reach their own dossier and journal through signed, expiring magic links tied to their email — no shared passwords, no account to breach.
• Messaging stays in the portal. Two-way messages between a practitioner and a patient live behind that same magic-link portal — not in personal email threads or WhatsApp chats, where special-category health data has no business sitting. Threads are scoped to the clinic, so one practice can never read another's.

How the AI assistants handle your data

• Scoped to your clinic only. The intake, dossier and practitioner assistants are given only the records belonging to the signed-in clinic. The data is filtered to your clinic on the server before it ever reaches the model — another clinic's records are never placed in the assistant's context.
• The assistant cannot fetch data on its own. It has no database access and no ability to call other systems; it can only work with the clinic-scoped information we hand it for that one request. So it cannot be instructed to "go and look up" anyone else's records.
• Resilient to prompt manipulation. Because the clinic boundary is enforced in our database layer beneath the AI — not by the AI's own instructions — manipulating the assistant's wording cannot make it cross into another clinic's data. We additionally screen intake text and AI output to keep the assistant within its intended, non-diagnostic scope.
• Not used for training. Intake text is processed in session to produce the response and is not retained or used to train models (Anthropic API terms).
• Dictation audio is processed in the EU, and never by us. The microphone button streams audio from your browser straight to Deepgram's EU endpoint (api.eu.deepgram.com), so the speech processing happens inside the European Union, under our own data processing agreement. MyDosha never receives or stores the audio — only the resulting text. Deepgram does not use it to train models under that agreement. Where dictation has not been enabled for a practice, the microphone falls back to your browser's own speech recognition, which in most browsers sends the audio to the browser vendor (Google for Chrome, Apple for Safari) under their terms. If you would rather no audio left your device at all, type instead of dictating.

Our subprocessors

We rely on a small set of established providers. Each processes only what its function requires, under a data-processing agreement. International transfers, where they occur, are covered by Standard Contractual Clauses.

Backups & recovery

The full database is backed up automatically every 6 hours. Each backup is validated for completeness (table coverage, row-count floors, referential integrity) so a half-failed dump is caught rather than silently kept. The archive is then encrypted before it leaves our infrastructure; the decryption key is held offline, so the storage provider cannot read patient data. We periodically restore a backup into a throwaway environment to confirm it actually works — an untested backup is not a backup.

Your rights & our commitments

• Your data stays yours. Clinic and patient records belong to the clinic. We act only on your documented instructions. We will never sell them, and we will never contact your patients.
• Data Processing Agreement. A signed DPA is available to every paying clinic, with EU Standard Contractual Clauses where relevant.
• Access, export, deletion. You can request a copy of, or the deletion of, your clinic's data at any time. Deletions of patient and clinic records run through audited, safeguarded routines.
• Breach notification. In the event of a personal-data breach, we will notify affected customers without undue delay, consistent with GDPR's 72-hour standard.
• GDPR Article 9. Health data is processed under the appropriate legal basis; see our privacy policy for detail.

Reporting a vulnerability

If you believe you have found a security issue, please email security@mydosha.org. We aim to acknowledge reports within 48 hours and welcome responsible disclosure. Our machine-readable policy is published at /.well-known/security.txt.

This page describes our security posture in good faith and may evolve as the product does. It is informational and does not by itself form part of any contract; the binding terms are in your service agreement and DPA.

Last updated: 1 September 2026