Privacy Policy

MyMed.bg is operated by Булфарма ООД, company no. 112064200, with its registered seat and address of management at гр. Пещера, ул. “Нешо Чипев” 1. The role under the GDPR depends on the specific purpose of the processing. Bulpharma OOD is an independent controller for the data needed to create and manage the MyMed.bg account, to authenticate the user, and for platform security, technical support, misuse prevention and its other own functions. For data relating to a specific medical booking — the healthcare provider, the doctor, the specialty, the date and time, the attendance status and any applicable card guarantee — the healthcare provider concerned — a clinic or a doctor’s own practice — is the controller; Bulpharma OOD processes that data through MyMed.bg as a processor on that provider’s instructions and under an Article 28 GDPR agreement. Email for data protection and for exercising your rights: [email protected].

The same identifier or contact detail may be processed in a different role depending on the purpose. For example, the phone number and email address are used by Bulpharma OOD as a controller to authenticate the account, while in sending a reminder about a specific medical appointment they may be processed by MyMed.bg as a processor on behalf of the healthcare provider concerned. The account may show past and upcoming bookings across different healthcare providers in one place. This combined view does not change the roles: each medical booking record remains the responsibility of the healthcare provider it relates to. Bulpharma OOD does not use the history of medical bookings for its own advertising profiling or to infer health interests. The split of roles is governed by an Article 28 GDPR agreement with each healthcare provider.

The purposes of the processing are to provide search and appointment booking, prevent double-booking, protect accounts and the platform, send approved booking communications, and meet legal obligations. Where no-shows are systematic, an automated rule reduces the online-booking allowance on a confirmed no-show and restores it with regular attendance; once it is used up it may block creating new online bookings. The rule uses only minimised no-show and attendance data and does not assess health status. You are notified when blocked and can request human intervention and review via [email protected]. In “Health portal” we show “Offers from clinics” — services that healthcare providers recommend. Which offers you see depends on the region in your profile, on whether you have a booked or attended appointment with that provider and, where the provider has set such criteria, on age and sex — yours and those of the family members in your profile. No diagnosis, symptom, note or visit reason is used for this selection. The provider never learns who saw or opened an offer — it receives only the total number of opens. The basis is our legitimate interest in showing relevant offers inside your own account; nothing is sent by e-mail, Viber or as a notification, and you can hide any offer. You can object to this processing at [email protected]. Candidate Article 6 bases include contract, legitimate interests and legal obligation as applicable. The Article 9 basis for each health-data flow — including whether explicit consent under Article 9(2)(a) applies — is determined according to the specific processing.

The register of recipients and processors names Hetzner for EU hosting/backups and Cloudflare for the edge, DNS and Tunnel. A second copy of the backups is kept in Google Drive; it is encrypted before upload and Google does not hold the key. The MyMed.bg mailboxes ([email protected] and [email protected]) are hosted by SuperHosting.BG in Bulgaria. SendPulse is used for the email and Viber payloads of the affected notifications; SMS is not used as a channel. You receive device notifications only if you turn them on in your browser yourself; the browser’s notification service (Google, Apple, Mozilla or Microsoft) then receives encrypted content and the technical address of the device. When you choose coverage through a health fund or insurer, its authorised staff see a minimised data set (e.g. name, appointment type and date, and coverage status) through a secure portal solely to confirm coverage; every access is audited and no EGN is provided. When a doctor enters the address of a new practice, the MyMed.bg server sends the typed address and the city to the Nominatim service of the OpenStreetMap Foundation (United Kingdom) to place the pin on the map. No name, account, email or the doctor’s IP address is sent. Where a practice takes payments, they are processed by Stripe on that practice's own account: card details are entered directly with Stripe and never reach us — we neither see nor store them. For those payments the practice is the data controller and receives the payment data from Stripe, while we keep only the payment and refund record — amount, status and a reference to the transaction. Taking payments through the platform is not currently active and will be introduced at a later stage. We do not use third-party advertising networks or tracking tools.

The main application database and the main backups are stored in the European Union. The second, encrypted copy of the backups in Google Drive may also be stored outside the EEA. Some global providers of infrastructure, security, communications, analytics or advertising services may process limited data outside the EEA. Where such a transfer occurs, an applicable mechanism under Chapter V of the GDPR is used — for example an adequacy decision, Standard Contractual Clauses, and supplementary measures where necessary. The specific mechanism depends on the provider and the country of processing.

Target retention periods apply to source and delivery records: booking history follows applicable legal/accounting rules; audit records are kept for 1 year; delivery records up to 12 months; OTP source rows up to 90 days; recipient addresses on closed staff invitations are anonymised after 30 days (for an invitee who never created an account, this scheduled anonymisation is also the erasure path — a request arriving inside the window is verified against the invited address and handled manually). Records a practice enters for walk-in patients without a platform account are part of that practice’s medical documentation: they are retained under the practice’s medical-record obligations, and access or erasure requests about them are handled by the practice as controller. A registered patient can schedule account closure from Profile › Security with a grace period of exactly 30 × 24 hours. The account remains usable during that period; signing in never cancels or postpones closure, and only an explicit cancellation before the deadline does. At the deadline cancellation closes and the request becomes due for the nightly queue; account access ends and eligible data is anonymised only when the erasure worker later processes it. Closure does not automatically cancel appointments or alter their time spans. Records required by law or integrity duties are retained in restricted or anonymised form, backups age out through controlled rotation and erasure replay, and copies already delivered to external mailboxes or retained in a browser/device cannot be remotely erased by the platform.

By default we use only the strictly necessary technologies for the session, security, language preference and storing your privacy choice. Your choice is kept in a single first-party cookie (mm_consent, or __Host-mm_consent in a secure context) for up to 180 days. Analytics and marketing technologies are activated only after explicit consent (Consent Mode v2, defaulting to “denied”) and can be switched off at any time from “Cookie settings” at the bottom of the site. Analytics and advertising technologies must not receive data about a medical booking, the chosen doctor, the specialty, the healthcare unit, the attendance status, or any other information from which health status could be inferred. They are not used for advertising profiling based on booking history.

We apply appropriate technical and organisational measures according to the risk, including an encrypted connection (TLS), one-way password verifiers, hashed session identifiers, role-based access controls, logging of administrative actions, backups, and logical separation of data between healthcare providers. Sensitive fields are stored encrypted, and row-level security policies (RLS and FORCE RLS) are installed, tested and enforced. Two-factor protection can be enabled from the security settings of any account; it is mandatory for health-fund staff and optional for everyone else. Access to booking data is granted to a limited group of authorised people according to role and healthcare provider. The measures are reviewed periodically and upon material changes or incidents.

Where a user books an appointment for their child or for a person they are entitled to represent, MyMed.bg collects only the patient details that are necessary, while the phone number and email address remain those of the representing user’s account. The user must have a legal basis to provide the data and to manage the booking. The platform does not by default require a national identity number (ЕГН), a copy of an identity document, or any other identity document for the sole purpose of booking online, unless a separate legal requirement applies to a particular service.

We may update this Policy where the platform, the providers, the roles or the legal requirements change. For material changes we will give appropriate notice. The date from which the current version takes effect is stated at the beginning of the document. 14/11/2026 — clarified that the comment check also confirms that a comment describes a visit to the doctor it is written for. 13/11/2026 — added a recipient: the Nominatim service of the OpenStreetMap Foundation receives the address a doctor enters for a new practice. 11/11/2026 — added a description of “Offers from clinics” in “Health portal” and of doctors’ own practices; clarified the recipients (mail hosting, the second encrypted backup copy, browser notifications), the audit-record period (1 year) and two-factor protection. 15/10/2026 — new section “Reviews and review invitations”.