Privacy policy

Who processes your data

Medaro is a medical directory for Armenia: a catalogue of doctors, clinics, pharmacies and laboratories, patient reviews, and a guide to compulsory health insurance. The portal does not provide medical care, does not book appointments and does not keep medical records.

The personal data controller is QWERTY LLC (Republic of Armenia), registration number 282.110.1073657, TIN 00922045. Postal address for legally significant correspondence: 44 Paronyan Street, Yerevan, Republic of Armenia. We accept personal data requests by e-mail at info@medaro.am — the same address is shown in the site footer.

The basis for processing

For registered users the basis is consent. During registration you tick two boxes: consent to the processing of personal data (this document, version v5) and consent to publishing your review under the portal rules. A doctor applying for verification ticks a third one — consent to the processing of diploma and licence documents.

Every consent is written to the log as a separate row: who agreed, to which document, in which version and at what minute. We do not write the IP address to that log, even though the database has a column for it.

A visitor without an account ticks nothing: the server request log, the anonymous site-search statistics, the Google Analytics counter and the maps work for everyone. What each of them collects, why and for how long is set out in the sections below. Notifications about new articles work differently: they are on only if you turned them on yourself — pressed the button on the site and then allowed notifications in the browser’s prompt. Those two actions are your consent; you can turn notifications off at any moment with a single tap (see “Notifications about new articles”). You also send a “Spotted an error?” message yourself: the form asks for an email address — as a rule, we send it a confirmation that the message has been received and, once the check is done, its outcome. By sending the form you agree that we use the address for emails about this message and, if needed, to ask you a question about it; the form cannot be sent without an address, but you can also simply write to us at info@medaro.am.

When this document changes in substance, we raise the version number, publish the new text on this same page and list what changed. Registered users who are signed in see a notice on the site that the policy has been updated, with a link to the new text. We do not collect consent again: the log keeps the record of the version you agreed to. If you do not agree with the new version, write to info@medaro.am and we will delete the account; what happens to your reviews is explained under “Your rights”.

What we store

The list is closed: the portal keeps nothing about you beyond what is named here.

• Account: email address, display name, interface language and role (patient, doctor, administrator). The password is stored only as an irreversible hash in the authentication service — we never see it. There is a phone field in the database, but we neither ask for it at registration nor fill it in.
• Sign-in sessions: the time of sign-in, the IP address and the browser string of every active session. The sign-in service keeps them to protect the account; the record is deleted when you log out. The sign-in service also keeps an event log (sign-in, sign-out, password change): the time and the account, without the IP address.
• Reviews: the text, the overall score and three facet scores, the language, the visit date, the doctor or organisation the review is about, the signature (“Name S.” or a pen name you choose), and the creation and publication dates. Your real name is never shown next to a review, and the internal link between a review and an account is closed at database level to everyone except you and a moderator.
• Visit confirmation: the date of the visit, the confirmation method and — if you confirm with a receipt — the receipt file itself in private storage. The file is needed only for the check and is deleted afterwards under our procedure.
• Doctor cards. Most cards were compiled by us from open sources — the websites of the clinics where the doctor works: name, specialty, position, place of practice, gender, photo. Under each photo we state the clinic, a link to the page it was taken from, and the date. A doctor can ask at any time to correct the information or remove the photo: with the “Spotted an error?” button on their page (request type “Remove or replace the photo”) or by email to info@medaro.am. Every request is reviewed by a moderator. To make sure the request really comes from the doctor or their clinic, we may ask for confirmation — for example, an email from the clinic’s official address. If it is decided to remove the photo, we take it off the page and out of storage at once, and out of the Cloudflare cache and the site’s backup copy the same day. A doctor who has verified the profile then fills it in themselves: education, years of experience, languages, description, consultation price.
• Doctor verification documents (diploma, certificate, licence): held in private storage and available only to that doctor and to a portal administrator. They are never shown to patients.
• Doctors’ replies to reviews and reports about reviews, together with the reason given and the status of the case.
• “Spotted an error?” messages: the text, the time it was sent, the page it refers to (its address and title), the request type, the page language and the email address you gave — the form cannot be sent without it; we no longer accept phone numbers. We also store the moderator’s decision and records of the emails to that address: when the “received” email and the email with the outcome of the check went out, and, if an email was not sent or bounced, why (for example, “the domain has no mail” or “the address does not exist”); if the address has been deleted — when and for what reason. The address is seen by moderators in the site’s admin panel and by our program that sends the emails; it is not published on the site and is not added to any mailing list. We need this data to correct the information or consider a photo request; the address is for emails about this message (the confirmation of receipt and the outcome of the check) and, if needed, to ask you a question about it. So that the form cannot be turned into a mailing tool, the emails go out with limits, among them: no more than one “received” email per address per day, and no more than 20 emails an hour and 100 a day in total; we do not write to an address to which our emails bounced or were rejected in the last 90 days. The message still reaches the moderator. If the page has been hidden from the site by the time the form is sent, no emails are sent at all. There may be no email with the outcome if the first email did not arrive or the address turned out to be invalid, if the message is not about the information on the page, or if the email limit has been reached; we answer a photo request with a separate email from the info@medaro.am mailbox.
• Service logs: the consent log and the log of moderator and administrator actions (who changed what). It exists so that decisions on reviews and verification can be audited.
• Server request log: the time, IP address and country, browser and device type, the full address of the page opened, the response code; for file uploads, also the account and the file. Why we keep it and who sees it is described under “Server request log”.
• Site-search statistics — anonymously: the query text, the section, the language, the day, how many times it was searched for and how much was found; the table itself holds nothing that links a query to you. See the statistics section for details.
• Letters to clinics: the address we wrote to, the organisation, the date of sending, and the marks that the letter was opened and which links in it were clicked. This is data from business correspondence with an organisation, not with a patient.
• Letters you send to info@medaro.am — in our mailbox (see “Who we share data with” about email); the same mailbox holds copies of our emails about “Spotted an error?” messages and non-delivery notices.
• A subscription to notifications about new articles — only if you turned them on: the delivery address your browser issued, the two encryption keys that go with it, the notification language, the topic, the delivery service, the version of this document, the date you subscribed and the dates of the latest delivery attempts. The subscription holds no IP address, no information about your device and no link to an account. See “Notifications about new articles” for details.
• Backups. So as not to lose data in a failure, every night we copy the database and the file storage; the copies contain everything listed above. They are kept on our server, on the portal administrator’s work computer and, encrypted, in Google Drive — only we hold the encryption key, so Google cannot see the contents. Daily copies are kept for 30 days, and copies taken on the first day of the month for up to 3 months. No backup is kept longer than 3 months, so deleted data disappears from the backups for good within 3 months at most.
• The camera, your location and notifications are switched on only with your permission: the camera for the visit QR-code scanner in the review form, the location for the “Near me” button on the map, notifications for new blog articles. The camera image and your coordinates are not sent to our server; only the visit code that was read is sent.

The cookies we set

There are no advertising networks or tracking pixels on the pages of the portal — the one pixel we use sits in the letters we send to clinics, described below. There is exactly one external traffic counter — Google Analytics; the portal also keeps its own internal statistics, described in the section below. So the cookies come in two kinds — four technical ones of ours and two of the counter.

• sb-medaro-auth — the sign-in session: appears after you log in and is deleted when you log out; if you do not log out, the browser keeps it for up to 400 days. Without it signing in is impossible. If it holds a lot of data, the browser splits it into parts (sb-medaro-auth.0, sb-medaro-auth.1) — it is still the same cookie.
• sb-medaro-auth-code-verifier — a one-off service cookie for the time of email confirmation and password recovery; once you are signed in it is no longer needed.
• NEXT_LOCALE — the selected interface language: set only when you switch language or open medaro.am without a language in the address, and lives until you close the browser.
• medaro_vid — a random identifier with no meaning of its own. It is set only when you open the page of a doctor who has verified their profile on the portal, lives for 48 hours and is needed for exactly one thing: so that the same visitor is not counted twice in one day.
• _ga — a cookie of the Google Analytics counter: a random number for your browser, by which the counter tells a first visit from a repeat one. It holds no name, no email address and nothing from your profile. It lives for up to two years; the browser may shorten that (Chrome to 400 days, Safari to 7 days).
• _ga_JQZD411NCY — the second cookie of the same counter: it holds the state of the current visit — when it began and how many pages have been opened. It lives for up to two years; the browser may shorten that in the same way.
• If your browser sends the “Do Not Track” (DNT) or Global Privacy Control signal, our doctor-page statistics do not count you and do not set the medaro_vid cookie, and your site searches do not enter the search statistics. Google Analytics ignores this signal — you can switch it off with the Google add-on or a blocker (see “Who we share data with”).

A few more details for completeness — these are not cookies but notes and permissions the browser keeps on its side. Until the consent record is created in the database, the browser keeps a local note that the boxes were ticked; it disappears as soon as the consent is written. If you close the notice about an updated policy, the browser remembers that with a similar local note so as not to show it again; on another device or after clearing the browser the notice will appear once more. If you turned on notifications about new articles, the browser keeps your permission for medaro.am; a small service script that displays an incoming notification and opens the article when you tap it (it stores no pages and no data, and is removed when you turn notifications off on the site); and a note with a short fingerprint of the delivery address — not the address itself — plus the notification language and the version of this document: from it the site can tell that the subscription has not changed and does not contact the server on every visit. If you pressed “Not now” under the offer to turn notifications on, the browser remembers the date, and we do not offer them again for 90 days. For portal administrators who marked their own device to receive test notifications from the admin area, the browser keeps one more note — the same short fingerprint of the delivery address — so that the bell window can show that mark. These notes are never sent to the server.

Our own statistics: doctor pages, site search and letters to clinics

The portal counts how many times during a day the page of a doctor who has verified their profile was opened and how many times the “Call” button on it was pressed. The doctor sees these two numbers in their dashboard and uses them to judge how the profile performs.

Only the daily total is stored: the doctor, the date, the kind of event and the number. No IP address, no user agent, no page URL and no exact event time are kept, so an individual person cannot be reconstructed from this table.

The identifier from the medaro_vid cookie never reaches the database: before writing it is turned into an irreversible hash together with a server-side secret. The table that tells us this visitor has already been counted today is cleared automatically after two days.

The statistics are tied neither to your account nor to your profile: the daily total contains no user identifier and no visitor identifier.

One honest caveat: at the moment of a request our server sees both the technical cookie and — if you are signed in — your session, because they arrive together in the same request. They are not linked in storage, but it would be untrue to claim that such a link is technically impossible.

Since version v3 the portal also counts what people search for on the site — to see which doctors, clinics, tests and services the catalogue is missing. This covers the search for doctors, clinics, laboratories and conditions, the search on the map and, on organisation pages, the search in the price list and in services under state health insurance. Until now, the text you typed into the search for clinics, tests, conditions, the map or a price list never left your browser; now, when you stop typing or leave the page, the result of the search goes to our server: the query itself, the site section, the page language and the number of results found. Intermediate variants while you type are not sent. The query text does not go to Google: it is cut out of the page addresses the Google Analytics counter sees, and the counter’s “Site search” feature is switched off.

Only the daily total is stored: the query, the section, the language, the date, how many times it was searched for, how many times the search found nothing and how many results the latest search found. The query is reduced to a plain form (lower case, no extra spaces or punctuation) and cut to 64 characters. Queries that look like an email address, a website address, a phone number or a document number (five or more digits in a row, or six or more digits in total) are dropped entirely — already in the browser and again on the server. With the “Do Not Track” or Global Privacy Control signal on, the query is not counted. The IP address is not written to the statistics table: the server keeps it only in memory — so that one person is not counted many times a day and to guard against inflated counts; a repeat of the same query from the same IP address within a day is counted once. There is no cookie, device, account or exact time in this table either, so this table alone cannot tell who searched for what. But the very fact that a search result was sent, like any request to the site, enters the server request log — with the IP address and the time, without the query text. And the doctor search changes the page address, and the log records such an address in full, together with the search text (see “Server request log”). Only portal administrators see the totals.

An honest caveat here too: if someone types a person’s name into the search, it is stored as query text — with no link to whoever searched, but it is stored. If such a query needs to be removed, write to info@medaro.am — we will delete it from the statistics, and it will leave the backups within 3 months at most. So that it is not counted again, the query text itself stays only in a closed exclusion list — with no counts and no search dates; only administrators see that list.

Letters to clinics are a separate story. We write to the management of clinics, pharmacies and laboratories at the addresses they have published on their own websites: we tell them about the portal and link to their page in the catalogue. This is business correspondence with an organisation; we never use patients’ addresses for such letters.

In such a letter we see two things: that it was opened — through a transparent one-pixel image that the mail program loads from our server — and which links in it were clicked: “Open the clinic page”, the video about the portal, or simply the site address. The links run through our own domain, and where each of them leads is fixed on our server behind a short keyword: an outside site cannot be slipped into such a link. We count this for one purpose only — to understand whether the mailing is of any use and whether it is worth writing again.

What is stored: the address the letter went to, the organisation, the date it was sent, the marks that it was opened and which links were clicked, and the line by which the mail program or browser introduces itself. The last one is needed to tell a live opening from a preload by a mail service. We do not store the IP address in the mailing tables: what matters to us is the response, not where you connected from. Loading the images of a letter and following its links are ordinary requests to our server: they enter the request log with the full IP address and the full address of the link, including the letter’s code, so the log shows which organisation the letter was sent to. Marks about openings and clicks are kept for 6 months, the record of the letter itself for 12 months from the day it was sent.

Opting out is simple: reply with a single word — “no”, “stop”, “unsubscribe”, any of them will do — and we strike the address off the list; there will be no second letter. No explanation is needed. The same reply can be sent to info@medaro.am. A request not to write again we remember even after the remaining records about the letter are deleted — otherwise we would forget it and write again.

One honest caveat here too: “the letter was opened” is an estimate, not a fact. Apple and Google mail apps often load the images in a letter by themselves, before the person has even seen it — the opening is counted although nobody started reading. So we treat only a click on a link as a fact, and the number of openings as an approximate estimate.

Server request log

Since version v3 our server keeps a log of requests to the site. Its purpose is security, failure analysis and the investigation of abuse: to see attacks, break-ins, password guessing and abuse, and to know who uploaded what to the site. Pages that Cloudflare serves from its own cache never reach our server and do not enter the log.

For each request the log records: the date and time; the IP address in full (Cloudflare passes it to our server) and the country derived from it; the line by which the browser introduces itself (user agent) and the device type derived from it — phone, tablet or computer; the request method; the full page address, including the parameters after “?”; the response code, its size and how long it took to prepare; and the site you came from — its domain only.

The page address is recorded in full. It shows which page you opened — for example, the page of a particular doctor, clinic, laboratory or condition — which filters you chose and what you searched for, if the search text was in the address. The IP address is recorded in full for every address, including the service addresses of our statistics and the images and links in letters to clinics. There is one exception: the values of sign-in parameters — one-time codes and keys from email-confirmation and password-recovery letters and the like — are replaced with the mark “[скрыто]” (Russian for “hidden”), so that the log cannot give access to other people’s accounts. The part of the address after “#” is never sent to the server by the browser at all.

What the log does not contain: what you send in the body of a request — form contents (except what the browser itself puts into the page address, such as the doctor search text) — passwords, cookies, the text of reviews and messages, or the account you are signed in with. The exception is uploading files to the site (currently, documents for doctor verification): uploads go to a separate upload log — the time, IP address, country, browser, the account that uploaded the file, the file name and type, size and result. It also records when and from which IP address these documents were opened. The notification delivery address and its encryption keys are also sent in the body of the request and do not get into the log; turning a subscription on or off, or updating it, is recorded like any other request — with the IP address, browser and time. Sending the “Spotted an error?” form gets into the log like any other request — a line with the IP address, browser and time, without the message text or the email address. The message itself is stored in the database with the exact time it was sent, so a server administrator can match a message to an IP address by time. To protect against abuse, the server limits how often the form can be sent by IP address, which it keeps only in memory and does not write to the database.

The technical logs of the server’s services — file storage, gateway, sign-in service, tunnel — may also contain IP addresses: for example, the storage records one for every request for a doctor’s photo. These logs are limited in size and are overwritten as they fill up — at today’s traffic, after roughly 1–5 weeks.

The logs are kept only on our own server in Armenia and are not included in backups. Only server administrators have access to them. We pass them to no one and combine them with nothing — neither with Google Analytics nor with accounts; we may disclose records only on a lawful request from an authorised state body. The request log and the upload log are kept for 12 months, after which records are deleted automatically.

The log covers all requests, including those with the “Do Not Track” signal on: it is not traffic statistics but protection of the site. Records are tied to an IP address, not to a name. To find out what the log holds about your IP address, write to info@medaro.am stating the address and the approximate time.

Notifications about new articles

From version v4 you can receive notifications about new articles in the Medaro blog — on your phone or computer, even when the site is closed. They never switch themselves on and never pop up by themselves: you need to press the consent button — at the end of an article or in the bell window in the site header — and then allow notifications in the browser’s prompt. Until you do, the site registers nothing in your browser and asks for no permissions. There is one topic — new blog articles. There are no topics about diseases or specialties and there will be none: choosing such a topic would in itself be information about health.

When you turn notifications on, the browser issues a delivery address — a long random link to the server of a delivery service that knows which browser on which device should receive the message — and two keys used to encrypt the notification text. We store them together with the notification language (the language of the page where you turned them on), the topic, the name of the delivery service (Google, Apple, Mozilla or Microsoft — we work it out from the address), the version of this document, the date you subscribed — without the time — the dates of the last successful and the last failed delivery, and the number of failed attempts in a row. Devices belonging to the portal’s own administrators also carry a “receive test notifications” mark.

What the subscription does not hold: an IP address, the browser string, the device model or any other information about the device, a link to an account — even if you are signed in — your history of visits to the site, or any record of which notification was shown to you and whether you opened it. We deliberately do not keep the time you subscribed: with the exact time, a subscription could be matched with an entry in the server request log. To guard against abuse, the server limits how often subscriptions can be turned on and off by an irreversible hash of the IP address, which it keeps only in memory and never writes to the database. If your browser’s delivery service is unknown to us, no subscription is created: we only note the name of that service’s server and how many times someone tried to subscribe through it — for 12 months, to decide whether it is worth supporting. The site’s admin area shows only totals: how many subscriptions there are, in which languages and with which services, how many people subscribed and unsubscribed per day; there are no subscription addresses there.

The notification is prepared by our server — usually the title and first sentence of a new article with its cover image — in the language of your subscription, and it links only to pages of medaro.am. It is delivered not by our server but by the delivery service your browser chose: Google, Apple, Mozilla or Microsoft, all of them in the United States (see “Who we share data with”). The notification text is encrypted with your browser’s keys, so the delivery service cannot read it. A notification is visible on the device screen, including a locked one, so for articles on sensitive topics it arrives with a neutral title and no image.

Your device loads the notification icon and image from our addresses medaro.am and api.medaro.am, like any image on the site. The link in a notification carries the parameters utm_source=push and utm_medium=web_push and the name of the mailing — the same for every recipient: from them Google Analytics counts how many visits a mailing brought, and the server request log records the address as it is. There is nothing in the link that points to your subscription or device. We count only how many notifications the delivery services accepted; we do not track whether a notification appeared on screen or who opened it.

You can turn notifications off at any moment with one tap: in the bell window in the site header, with the “Turn off notifications” button. The browser drops the subscription, the record in our database is deleted at once, and the notification service script is unregistered. You can also block notifications for medaro.am in your browser settings, and on an iPhone or iPad remove the site from the Home Screen: the delivery service will then tell us at the next sending that the subscription no longer exists, and we delete the record. A subscription to which five notifications in a row could not be delivered, or which has had no successful delivery for more than 60 days while its latest attempt also failed, we delete during the nightly clean-up. Retention periods are listed under “How long we keep data”.

To be honest about it: the delivery address is a pseudonym, not a name, but the delivery service knows which browser on which device it belongs to — and often which Google, Apple, Mozilla or Microsoft account is signed in to that browser. We do not know that, but the request to subscribe is recorded in the server request log together with the IP address. That is why we treat a subscription as personal data and handle it like the rest: it is kept on our server in Armenia and, like everything else, goes into the backups.

Who we share data with

We sell data to no one and pass it to no one for advertising. Your records — the account, reviews, documents, notification subscriptions, the request log, search statistics — sit on our own server in Armenia; the portal uses no ad network and no CRM. There are six outside services through which data passes or where it is stored, and we name all six: Cloudflare, Google Analytics, OpenStreetMap, Zoho Mail, Google Drive and PowerDMARC. If you turn on notifications about new articles, a seventh is added — your browser’s notification delivery service.

Cloudflare. The site runs through the network of Cloudflare, Inc. (USA): it protects against attacks, speeds up loading and connects visitors to our server. Every request to medaro.am and api.medaro.am passes through its nodes, so Cloudflare sees your IP address, page addresses, browser details and whatever you send to the site, including form contents — such a service cannot work without that. If a connection fails, the browser may send Cloudflare a technical error report: the page address and the type of failure.

Backup copy of the site at Cloudflare. So that the portal stays readable when our server is down, every night we store at Cloudflare a copy of the public pages — only what everyone can see anyway: the catalogue, doctor cards and photos, organisation pages, published reviews, articles. Accounts, email addresses, unpublished reviews, documents, the request log and statistics are not in the copy. While the server is down you see this copy, and sign-in, forms and text search do not work. Anything removed from the site disappears from the copy with the next nightly snapshot, and a doctor’s photo that it has been decided to remove on request disappears the same day.

Google Analytics. The pages of the portal run the Google Analytics traffic counter — a service of Google LLC (USA). The data is processed on Google servers in the USA and other countries, that is, it is transferred outside Armenia. The counter sees: the address of the page opened — without the part after “#”, without sign-in codes and without search text; which page you came from; how long you stayed and how far you scrolled; clicks on links to other sites and file downloads; the start and submission of forms — without what you typed into them; since version v3, clicks on phone numbers and “Call” buttons (except short and emergency numbers) and on links to Google Maps, Yandex Maps and 2GIS, including in the “Get directions” block: what was clicked, in which part of the page and on the page of which organisation or doctor, without the phone number and without your location; as well as your IP address, device, browser, language and approximate location down to the city. We pass it no name, no email address, no phone number and nothing from your profile. In “My account”, the doctor’s dashboard and the administration area there is no counter at all. The counter’s advertising features are switched off: Google signals, ad personalisation, links to Google advertising accounts. Google Analytics keeps detailed visit data for 14 months; if you come back to the site, the period for data linked to your _ga cookie starts again. We need the counter for two things: to know how many people come and which sections they read, and to see whether the portal helps people call a clinic and get there. You can opt out — the official Google add-on (tools.google.com/dlpage/gaoptout) switches this counter off on every site at once; ordinary blocking of tracking scripts in the browser works too.

Notifications. If you turned on notifications about new articles, we send them through the delivery service chosen by your browser, not by us: Google (Chrome, browsers on Android and most Chrome-based browsers), Apple (Safari on iPhone, iPad and Mac), Mozilla (Firefox) or Microsoft (Edge). All four are US companies, so the delivery address and the encrypted notifications are transferred outside Armenia. The service cannot read a notification: it is encrypted with your browser’s keys. What it sees is that medaro.am sent a message to this address, when, and how large it was. Your browser is connected to this service regardless of us — that is how it receives notifications from any site; how the service handles that data is described by the maker of your browser.

Maps. On the “Map” page and in the mini-maps on the pages of clinics, pharmacies, laboratories and pharmacy and laboratory chains, the base layer is loaded from the OpenStreetMap servers (tile.openstreetmap.org; OpenStreetMap Foundation, United Kingdom). Your browser talks to them directly: they see your IP address, your browser, the fact that you came from medaro.am (the address of the particular page is not passed) and which part of the map is shown — in a mini-map, the area around the organisation you are viewing. If you press “Near me” on the map, the map servers receive the areas around your location; the coordinates themselves are sent neither to us nor to OpenStreetMap. Fonts and images are served from our own domain; apart from the services named in this section, the browser talks to no one.

Links to Google Maps, Yandex Maps, 2GIS and to clinics’ websites lead to other people’s sites: nothing is passed to them until you click, and after that their own rules apply.

Email. The portal’s email runs on Zoho Mail (Zoho Corporation; our mailbox is hosted in a Zoho data centre in the USA). Registration confirmations, password recovery emails, letters to clinics and emails to people who sent a “Spotted an error?” message — the confirmation of receipt, the outcome of the check and the moderator’s replies — go out through Zoho. Copies of these emails remain in the “Sent” folder of the info@medaro.am mailbox; if an email is not delivered, a non-delivery notice with the address the email did not reach arrives in this mailbox. Our program reads such notices without changing anything in the mailbox, to mark on the message that the email bounced. Before sending a form email it checks through the Domain Name System (DNS) whether the domain of the address accepts mail — only the domain is looked up, not the address itself. The info@medaro.am mailbox also holds the letters you send us — including requests about your data and opt-outs from the mailing. Zoho sees the addresses, subject and text of the letters. The portal has no mail server of its own.

Google Drive. Encrypted backups of the database and files are stored in Google Drive (Google LLC). Only we hold the encryption key, so Google sees encrypted files, not their contents.

DMARC reports. So that no one can send letters in the name of medaro.am, mail services that receive letters with our address as the sender send reports about them. These reports go to the PowerDMARC service of MENAINFOSEC, Inc. (USA, State of Delaware; the service’s data is hosted on Amazon Web Services servers), which means they are transferred outside Armenia. The reports contain technical data about letters sent in the name of medaro.am: which mail server sent them, how many, and whether they passed authentication. Detailed reports about letters that failed authentication may contain recipients’ addresses — yours, for example, if our letter to you failed the check — and letter headers: sender, recipient, subject, date. We need the reports for one thing: to notice forgery of our address in time and protect recipients from it. PowerDMARC keeps them under its own terms (powerdmarc.com/privacy-policy): as long as needed to run the service and as required by law, and after that only in anonymised form.

We are obliged to hand over data only on a lawful request from an authorised state body. We have no other grounds for disclosure.

How long we keep data

The retention periods in force today.

• Account, reviews and doctor profile — for as long as you use the portal.
• Sign-in sessions on the server — until you log out; the sign-in service event log — 12 months.
• Rejected verification documents — 90 days, after which the file is deleted from storage.
• Daily statistics for a doctor — 400 days.
• The table that records “this visitor has already been counted today” — 2 days.
• Site-search statistics (anonymous daily totals) — 24 months; queries that have only ever been searched for once — 90 days.
• The server request log and the file upload log — 12 months.
• Technical logs of the server’s services — roughly 1–5 weeks at today’s traffic: they are limited in size and overwrite themselves.
• Visit data in Google Analytics — 14 months.
• DMARC reports at PowerDMARC — under that service’s terms: as long as they are needed for it to work and as required by law.
• Notification subscription — until you turn it off. If the delivery service replies that the subscription no longer exists (you blocked notifications or removed the browser), we delete it at once; if five notifications in a row could not be delivered, or there has been no successful delivery for more than 60 days and the latest attempt also failed, it is deleted in the nightly clean-up. Totals on subscriptions and mailings, with no addresses, and the texts of sent notifications — 24 months. The “Not now” note in the browser is in effect for 90 days.
• Cookies: sb-medaro-auth until you log out, but no longer than 400 days; sb-medaro-auth-code-verifier until sign-in is complete; NEXT_LOCALE until you close the browser; medaro_vid for 48 hours; _ga and _ga_JQZD411NCY for up to two years (the period is set by Google Analytics, and the browser may shorten it). Any of them can be deleted in your browser settings at any moment.
• The consent log and the moderator action log are kept for as long as we need them to demonstrate that processing was lawful and that decisions on reviews were justified.
• “Spotted an error?” messages and the records of emails — until the message has been dealt with and for 12 months after that. In a message that has not been dealt with, we keep the email address for no longer than 12 months from receipt: after that we delete it and the message stays without an address; earlier — at your request (see “Your rights”). Copies of our emails and non-delivery notices in the info@medaro.am mailbox are kept like the rest of the correspondence — see the item on that mailbox below.
• Letters to clinics: marks about openings and clicks — 6 months; the record of the letter itself — 12 months.
• Letters in the info@medaro.am mailbox — with no time limit: this is our correspondence with you and with organisations, including your requests about your data, copies of our emails about “Spotted an error?” messages and non-delivery notices.
• Backups of the database and files: daily ones for 30 days, those taken on the first day of the month for up to 3 months; no backup is kept longer than 3 months. The copy of the public pages at Cloudflare is replaced with a new one every night.

Your rights

You have the right to obtain a copy of your data, to correct it, to delete your account and to withdraw consent.

Some of this is not yet available as a button: the “My account” section shows your reviews and their status, but there is no self-service account deletion on the site yet. Write to info@medaro.am from the address the account is registered to and we will carry out the request and reply by email. We will delete the email address from a “Spotted an error?” message before the deadline if you reply to our email or write to info@medaro.am; the message itself stays without the address, and copies of emails already sent remain in the info@medaro.am mailbox like the rest of the correspondence.

Notifications about new articles are turned off without writing to us — in the bell window in the site header or in your browser settings (see “Notifications about new articles”). A subscription is linked neither to an account nor to an email address, so we cannot find it by your name or email: it can be turned off only on the device where it was turned on.

About reviews specifically: when an account is deleted the reviews do not disappear from doctors’ pages — they lose the link to you and stay anonymous. Otherwise ratings would lose scores retroactively and the picture other patients see would be distorted. If you want the text of your own review taken down, say so in the message.

What changed in version v5

Compared with version v4 of 9 October 2026.

• In the “Spotted an error?” form an email address is now required, and we no longer accept phone numbers. As a rule, the address receives a confirmation that the message has been received and, once the check is done, its outcome; the text of your message is not in these emails. The address can be deleted before the deadline.
• We keep records of the delivery of these emails and read non-delivery notices in our own mailbox. The emails go out through the same Zoho Mail — there are no new services.
• Requests to remove a doctor’s photo are reviewed by a moderator; to make sure the request comes from the doctor or their clinic, we may ask for confirmation.
• The sections “The basis for processing”, “What we store”, “Server request log”, “Who we share data with”, “How long we keep data” and “Your rights” now cover what concerns the “Spotted an error?” form and doctors’ photos; everything else is as in version v4.