This page is published in English as the authoritative version. Translations of headings are provided for convenience; the legal text below remains in English.
Legal documents governing the use of the MyDosha platform. Last updated: 25 October 2026 (section 7: Hostinger and Supabase agreement status stated as it is).
MyDosha ("we", "our", "the platform") is an AI-powered patient intake service for Ayurvedic practitioners. This Privacy Policy explains how we collect, use, store, and protect personal data in connection with the MyDosha service at mydosha.org and its subdomains.
We are committed to processing personal data in accordance with the General Data Protection Regulation (GDPR) (EU) 2016/679 and applicable Dutch data protection law.
This policy applies to these categories of data subjects:
A practitioner can also send a new patient one of the practice's own questionnaires instead of the intake assessment. The patient then gives the same explicit consent on the questionnaire's first screen, enters their name and email, and answers the practitioner's questions. The answers are stored exactly as written, and answers the practitioner linked to a record field (for example phone number or date of birth) are copied into that field. Submitting a questionnaire does not start any AI processing.
Patient health data is special category data under GDPR (Article 9). It is processed on the basis of explicit consent obtained from each patient during the intake process. Patients are clearly informed about the purpose and scope of data collection before providing consent.
During a trial we email the practitioner's trial address account notices (access, the trial end date, what happens at the end) and, separately, a few tips on using MyDosha. The tips use only counts of how the practice has used the service, such as whether a care plan has been sent; they never contain patient data. Purpose: helping a new practice get started and deciding whether to continue. Legal basis: our legitimate interest in onboarding our own customers (Article 6(1)(f) GDPR) and the existing-customer rule for electronic mail marketing. For practices in the Netherlands and Germany the tips are sent only to practices that ticked the box for them at signup. You can stop the tips at any time, free of charge, with the unsubscribe link in each email or on the email preferences page; account notices are service messages and continue while the trial runs. Links in these emails pass through a redirect on mydosha.org that counts the click; we use no tracking pixels and do not measure whether an email was opened.
We do not use patient data for any marketing, profiling, or purposes beyond the clinical intake service. We do not sell personal data to any third party.
MyDosha does not share patient data with health insurers, other healthcare providers, accountants, or other third parties on the practitioner's behalf. If a practitioner shares an exported file, care note, referral, or invoice outside MyDosha, that sharing is controlled by the practitioner and should follow their own confidentiality, consent, and professional-record obligations.
The intake conversation, dossier generation, practitioner AI chat, plan-drafting support, the opt-in practice operations assistant (which proposes administrative actions such as appointments, invoices and stock changes — the practitioner must confirm each one before it is applied, and confirmed actions are audit-logged), dictation parsing, import parsing, and polish tools may be powered by Anthropic's Claude API. Patient responses and relevant practitioner-entered context are transmitted to Anthropic only for the AI feature being used. Anthropic processes this data as a data processor on our behalf, under a data processing agreement. Anthropic's own privacy policy governs their handling of data: anthropic.com/legal/privacy.
Patient data is not used to train Anthropic's AI models under the current API terms. Anthropic's published API retention position is that API inputs and outputs are normally deleted from its backend within 30 days, except where a different contract, zero-data-retention agreement, policy-enforcement need, or legal requirement applies.
Practitioners can disable AI globally or per feature from Account & Settings. The available controls cover AI patient intake, AI dossier generation, AI chat and text polishing, AI dictation parsing, and AI import parsing. These controls are enforced server-side.
Speech-to-text (dictation). When a practitioner uses the microphone button to dictate notes, the audio is streamed from the practitioner's browser directly to Deepgram, Inc., which converts it to text on our behalf as a data processor under a data processing agreement incorporating the EU Standard Contractual Clauses. The audio is sent to Deepgram's EU endpoint (api.eu.deepgram.com), so the speech processing itself takes place inside the European Union. The audio does not pass through or rest on MyDosha's servers — we receive only the resulting text, which may then be passed to Anthropic for the sorting and polishing described above. Deepgram does not use the audio to train its models under our agreement. Practitioners who prefer that no audio leave the device at all should type instead of dictating, or disable AI dictation in Account & Settings.
Where dictation has not been enabled for a practice, the microphone falls back to the browser's own speech recognition. In that case most browsers send the captured audio to their vendor's speech service — Google for Chrome and Chromium-based browsers, Apple for Safari — under that vendor's terms, not ours, and MyDosha neither receives nor stores it.
Patient intake data (including special category health data under GDPR Article 9) is stored by the following sub-processors. Each has a Data Processing Agreement in place that incorporates the EU Standard Contractual Clauses (SCCs, Commission Implementing Decision (EU) 2021/914) as the lawful mechanism for any transfer outside the EEA. Transfer impact assessments (TIAs) are carried out for US processors where a third-country transfer arises; some remain in progress.
api.eu.deepgram.com), so the speech processing itself takes place inside the European Union.
clinical_json column). Documents and images added to a patient's record as files (Article 9 health data, which can include tongue, face and skin images) are stored in a private Supabase Storage bucket in the same EU region (Frankfurt), never in a public bucket and never on Vercel. A file can only be opened through a signed link that expires within minutes. Where a practice switches it on, patients can also send photos to their practice in the patient portal's messages. Each such photo is a file in the same private bucket, sent only after the patient has agreed to it, with location data and other embedded details (such as EXIF and GPS data) removed by the patient’s browser before upload, and any that remain removed by our server before the photo is added to the patient record. These photos are shown to the practice and to the patient only, are never sent by email, are never analysed by software or AI, and the patient can remove a photo they sent at any time.
A practice can choose to hold an appointment as a video consultation inside MyDosha, without a third-party video service. This section describes what happens to personal data when it does. As with the rest of the patient data, the practice is the controller and MyDosha the processor.
The call itself. Sound and picture are encrypted end to end between the patient's browser and the practitioner's browser (WebRTC, DTLS-SRTP). Where possible they go directly between the two browsers; where not, they pass, still encrypted, through MyDosha's relay (see below). MyDosha never decrypts, records, stores or analyses the audio or video, and no AI is used during the call.
Setting up the connection. To find each other, the two browsers exchange a short technical description (a "session description": the media formats they support and the network addresses at which each can be reached). MyDosha passes this through its own servers and stores it for the duration of the consultation: it is deleted when the call is ended and otherwise by a daily clean-up once the appointment has been over for an hour, so within about a day of the appointment. It is never written to a log.
When a direct connection is not possible (for example on some mobile or company networks), the still-encrypted media is relayed through a relay server that MyDosha operates on its own server (see Hostinger in section 7). So on a relayed call the encrypted media does pass through MyDosha's server, but it is only forwarded: the relay cannot decrypt it and does not store or record it. It keeps a connection log (network addresses, times, data volume) for 7 days, for security and abuse handling, and nothing else. No third-party relay or connection service is used.
The patient's link. The patient joins from a personal link sent by the practice. It identifies one appointment, works only from 30 minutes before the start until one hour after the end, and needs no account or app. The link is carried in the part of the address that browsers do not send to servers, and the page removes it from the address bar as soon as it is opened.
Camera and microphone are used only after the patient allows them in their browser, and only on the call page.
An ambassador is a person or an institute who holds a MyDosha referral code and is paid a commission when a practice they referred subscribes. Ambassadors are a separate category of data subject: no patient data and no special category data under Article 9 GDPR is involved in this processing, and an ambassador never sees a patient record. The terms are the ambassador agreement, and clause 14 of that agreement says the same as this section in shorter words.
Controller. For ambassador data MyDosha is the controller, not a processor. The controller is the entity named at the top of this policy.
What we hold. Name, email address, the referral code itself, the personal link, the display name and optional introduction for the public page, the record of accepting the ambassador agreement (the name typed, the date and time, the IP address, the agreement version and the country and version of the Media Kit accepted with it), payout and invoicing details supplied by the ambassador (set out below), the earnings ledger (commission accrued, clawed back and paid), the correspondence we exchange and, for an ambassador who uses the ten-practice reward in clause 9 of the agreement, the link to their own MyDosha practice account and the dates of any reward period. We use that link only to apply the reward to their own subscription (Article 6(1)(b) GDPR); it involves no patient data. The ledger records how many practices an ambassador referred and how much each accrued; the ambassador's own view never identifies those practices.
Before anyone is an ambassador: an application. Anyone can apply on mydosha.org/ambassadors (or its India version). For an application we hold what the form asks for: name, email address, country, practice or organisation and website if given, the personal link the applicant would like, an estimate of how many practitioners they can reach, the few lines they write about themselves, and whether they declared that they are not registered as a practitioner of an Indian System of Medicine in India (with NCISM or a State Board), which we use to check eligibility. We use it to decide whether to offer the agreement and to reply. The legal basis is Article 6(1)(b) GDPR, steps taken at the applicant's request before entering into a contract. With each application we also store the IP address it was sent from and the browser's user agent, to limit repeated or abusive submissions and keep the form secure; the legal basis for those two is Article 6(1)(f) GDPR, our legitimate interest in protecting the form, and an applicant can object to it. A copy of each application is emailed to our own inbox, sent through Resend, so we can read and answer it. If we approve it, the application is linked to the ambassador record described here and is kept for as long as that record is (see Retention below). If we do not, we keep it only so we can answer the applicant and recognise a repeat application: a rejected application is deleted automatically 12 months after we rejected it, and an application we never decided is deleted 12 months after it was sent. Either can be deleted sooner on request.
Payout and invoicing details. After accepting the agreement, an ambassador enters the details we need to pay them and to match their invoice: the account holder's name, country and payout currency; for euro, the IBAN and, optionally, the BIC; for Indian rupees, the bank account number and IFSC; optionally a VAT ID, GSTIN or PAN; and an invoice address. We use them only to pay commission under the agreement (Article 6(1)(b) GDPR) and keep the payment records tax law requires (Article 6(1)(c) GDPR, retention as set out below). Before the details are saved, the ambassador page shows a short notice of this purpose and asks for the ambassador's consent to it, and we record the time of that consent with the details (for ambassadors in India this is the written consent the Information Technology (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules 2011 ask for). They are never written to our logs; our own admin view shows them masked, and the full values are opened only by the person recording a payout, which is itself logged without the values.
The ambassador's public page. While an ambassador is active, their personal link (for example mydosha.org/your-name) opens a short page from the moment they accept the agreement. It shows the display name they chose or, until they choose one, the name on their ambassador record; the optional one-line introduction they wrote; their referral code, which is part of the signup link on the page; and a statement that they are a MyDosha ambassador who earns a commission if a practice subscribes. Nothing else about them is shown. The page asks search engines not to index it, and it is taken down the moment the ambassador is no longer active. The legal basis is Article 6(1)(b) GDPR: the page is part of what the ambassador asked us for, and they can change or remove the introduction from their ambassador page at any time.
Before anyone has agreed: a reserved link. When we are about to speak to someone about becoming an ambassador, we may reserve a personal link for them so the name is not taken by someone else. For a reservation we hold their name, the link name itself and, where we have it, their practice or institute — no email address, no referral code and no acceptance record. Nothing public names them: the reserved link redirects to ordinary signup, with the ordinary trial and no attribution, exactly as any unused link does, and there is no public page about them. The legal basis is Article 6(1)(f) GDPR, our legitimate interest in preparing a business conversation we are about to have; the entry is deleted on request, or when we decide not to proceed.
From a reservation to an ambassador record: two separate steps. The first is ours. Once the person has told us they want to take part, we activate the reservation: we add their email address, issue their referral code, and email them the agreement. That is the point at which the reservation becomes an ambassador record and everything set out above in this section applies to it — not the later acceptance. The legal basis from then on is Article 6(1)(b) GDPR, which covers steps taken at their request before the contract is entered into as well as its performance.
The second step is theirs, and it is a different event on a later day: they read the agreement and accept it by typing their name. That is what creates the acceptance record described above (the name typed, the date, the time, the IP address and the agreement version) and what makes their code and link start crediting practices to them. Between the two steps we already hold their name, email and code, and they are an ambassador in our records whose agreement is still outstanding.
Legal basis. Article 6(1)(b) GDPR, performance of the ambassador agreement, for name, email, code, payout details, the ledger and the payments themselves. Article 6(1)(f) GDPR, our legitimate interest in being able to prove which version of the agreement was accepted, for the IP address stored in the acceptance record; an ambassador can object to that processing at any time. Article 6(1)(c) GDPR, compliance with a legal obligation, for the invoice and payment records that tax law requires us to keep.
Recipients. Ambassador records are stored in our database at Supabase Inc (EU region, Frankfurt) and transactional email to ambassadors is sent through Resend. Both act as our processors under a data processing agreement; the sub-processor detail is in section 7 above. Payouts are made by bank transfer, so the ambassador's bank and ours see the payment. Ambassador data is never sold and is not used for advertising or profiling.
Retention. While the ambassador program relationship runs, and afterwards for as long as the tax and accounting law of the country where the operator is established requires the payment records to be kept. That period is set by those rules rather than chosen by us; the imprint says where the operator is established. When an ambassador accepts, we email them our countersigned copy of the agreement as a PDF; we do not keep the PDF itself, only a hash of the signed agreement. The hash and the acceptance record are kept for the duration of the agreement plus the statutory limitation period, and in any case no shorter than the payment records above, because together they are the evidence of the contract the payments were made under. Name and email are deleted on request once no payment obligation remains.
Rights. The rights in section 9 apply in full: access, rectification, erasure, restriction, portability, objection to the Article 6(1)(f) processing, and the right to lodge a complaint with the Dutch Autoriteit Persoonsgegevens (autoriteitpersoonsgegevens.nl) as our lead supervisory authority, or with the supervisory authority where you live (Article 77 GDPR). There is no automated decision-making with legal effect in this processing. Write to privacy@mydosha.org; section 9b explains how.
Ambassadors outside the EEA. Where an ambassador is established outside the EEA, we send them only what running the agreement needs, and any transfer of their own data out of the EEA rests on Article 49(1)(b) GDPR, because it is necessary to perform the contract with them.
We keep a record of the business relationships we build: practitioners, schools, partners and prospective ambassadors we talk to, and the people who take part in those business meetings. This is a separate category of data subject. It is never a patient record, and patient consultations are never recorded or uploaded into it.
Controller. For this data MyDosha is the controller, not a processor. The controller is the entity named at the top of this policy.
What we hold. Your name and, where relevant, your organisation, country and how we met; the status of the relationship and our own next step; the date, title and participant names of a meeting and our own written summary of it; the promises made in it (the exact wording, who made it, the due date, and a short quote or timestamp showing where it was said); and, for some meetings, a text transcript of the meeting (a .txt, .vtt or .srt file).
Transcripts. We store a transcript only of a business meeting, and only after the person uploading it has confirmed that everyone in the meeting was informed as required for the places involved and that it is not a patient consultation. Each upload records who confirmed that, when, and which wording they confirmed. If a transcript turns out to contain someone's health information, we delete it. A raw transcript is deleted automatically 90 days after upload unless we record a specific reason to keep it longer, for example as evidence of terms that were agreed, in which case we set a new deletion date no more than 12 months ahead and review the reason again on that date. It is kept only while that reason lasts.
Legal basis. Article 6(1)(f) GDPR, our legitimate interest in keeping an accurate record of our business conversations and of what each side promised. You can object to this processing at any time (Article 21 GDPR).
Who sees it and where it is kept. Only the founder's account can open these records; practices using MyDosha cannot. The records are stored in our database at Supabase Inc (EU region, Frankfurt), and transcripts in a private storage area at the same provider, which acts as our processor under a data processing agreement (section 7). No AI: summaries and promises are written by a person, and neither transcripts nor these records are sent to Anthropic or any other AI provider. There is no automated decision-making.
Retention. Transcripts as described above. Summaries, promises and the relationship record are kept while the relationship is active and deleted on request, or when we no longer need them. A deleted record or transcript can remain inside an encrypted backup copy until that backup expires or is destroyed; backups are never edited. This includes the offline backups we keep on encrypted drives, which copy stored transcripts as they were when the backup was taken and keep them until that backup is destroyed.
Rights. The rights in section 9 apply in full. Write to privacy@mydosha.org; section 9b explains how.
MyDosha is the data processor; the practitioner (or their clinic) is the data controller for patient records and is responsible for meeting the statutory retention requirements that apply to them. MyDosha is an intake and practitioner-workspace tool, not the practitioner's statutory long-term medical archive. We retain data while the practitioner's account is active and provide self-serve export tools so the practitioner can download and keep their own patient file archive before unsubscribing.
Practitioners must keep patient records for at least the longest applicable period below. These are controller obligations and floors, not ceilings.
| Jurisdiction | Medical / clinical records | Tax / invoice records |
|---|---|---|
| Netherlands | 20 years from last contact (WGBO art. 7:454 BW) | 7 years (Algemene Wet inzake Rijksbelastingen) |
| Germany | 10 years (BGB §630f); some specialties (radiology, transplant) longer | 10 years (HGB §257, AO §147) |
| United Kingdom | 10 years from last contact (NHS Records Management Code of Practice 2021); maternity 25 years; paediatric until age 25 | 6 years (HMRC; longer for VAT-registered businesses) |
| Portugal | 5–20 years depending on context (Decreto-Lei n.º 156/2005; hospital records 20 years) | 10 years (Código do IVA, art. 52) |
Where MyDosha is processor and the practitioner is controller, deletion requests normally reach us via the practitioner. If the practitioner has a legal reason to keep a copy, such as a WGBO patient-file duty or tax-retention duty in their own administration, that retained copy is the practitioner's responsibility outside MyDosha.
Data subjects have the following rights:
To exercise any of these rights, email hello@mydosha.org. Practitioners can additionally export their patient archive (CSV) self-serve from the practitioner portal at any time, satisfying the right to portability without contacting us. We will respond to direct requests within 30 days. You also have the right to lodge a complaint with the Dutch Autoriteit Persoonsgegevens (autoriteitpersoonsgegevens.nl) — our lead supervisory authority — or with the supervisory authority of your habitual residence (Article 77 GDPR). See the imprint for the full list.
French residents may lodge a complaint with the French data-protection authority (in addition to, or instead of, the Dutch lead authority, the Autoriteit Persoonsgegevens): CNIL — Commission Nationale de l'Informatique et des Libertés, 3 Place de Fontenoy, TSA 80715, 75334 Paris Cedex 07, France — www.cnil.fr. France transposes the GDPR via the Loi Informatique et Libertés (loi n° 78-17 du 6 janvier 1978, telle que modifiée par la loi n° 2018-493 du 20 juin 2018).
Email your request to privacy@mydosha.org (or tbthijs@gmail.com while that inbox is being configured). Please include:
We will acknowledge the request within 72 hours and respond substantively within one month of receipt, in line with GDPR Article 12(3). If the request is complex, we may extend this by up to two further months and will let you know why. There is no charge for a first request; repeated or manifestly unfounded requests may incur a reasonable fee.
If you are unhappy with our response, you can lodge a complaint with your national data protection authority — see the imprint for supervisory authority contact details.
MyDosha uses logs for security, accountability, support, and incident response. We do not treat logs as a practitioner medical archive, and we design logging paths to avoid storing secrets, full query-string URLs, patient free-text, or full patient records in runtime logs.
For a short operational overview, see Trust & AI Processing.
We implement appropriate technical and organisational measures to protect personal data against unauthorised access, loss, or disclosure. These include HTTPS encryption in transit, access controls on the practitioner portal, and limited staff access to patient data.
The practitioner portal is password-protected. Practitioners are responsible for maintaining the security of their portal credentials.
We may update this Privacy Policy from time to time. Material changes will be communicated to practitioners by email. The current version is always available at mydosha.org/privacy.