Website & Professional-Portal Privacy Notice
Last updated: 2026-10-11 · Applies to: this website and its professional portal (the SALUNOTE app has its own policy — what you enter there stays on your phone; the three things it can send us, each only when you choose to — an error report, a report to a professional you linked, and the receipt for a plan you collected — are described below).
Who we are
The Hyrcan Bio Data Team operates this website. Swiss data-protection law (FADP) and, where applicable, the GDPR govern the data described here. Questions and requests: contact@salunote.ch.
What this website processes, and why
Registrations. Doctors, nutritionists and trainers can register. We record which of the three you are, your name, email, phone, specialty or field, the country where you work, workplace (optional) and preferred language. A doctor also gives a medical licence number. A nutritionist or a trainer gives their certificates instead, and a professional registration number if they have one.
Certificates. They are uploaded with the registration, as photographs or PDF files, and they are used for one thing: so that an administrator can check your registration by hand, against the rules for the country you named. Only our administrators see them. They are never shown to patients, never on a public page, never in the portal and never sent to anyone. Before a certificate is stored, it is copied afresh on the same separate, isolated part of our server that handles photographs: each page becomes a new image made from what the page shows, without the details a camera, phone or PDF program writes into a file. Of a PDF, only the pictures of its pages are kept; any text layer, links, scripts or attachments it carried are not. The file as uploaded is not kept. Kept while your registration stands and deleted with the account; a rejected or withdrawn registration is deleted after 12 months together with its certificates.
Checking that we can reach you. Before a registration is created we send a six-digit code to the email address, and — where a text message can reach it — to the phone number, and ask you to type it back. Nothing is stored until you do. The reason is practical rather than bureaucratic: a mistyped address means our reply to you bounces into a mailbox nobody is watching, and you wait for a decision that was never delivered. The codes are stored only as a hash, expire in ten minutes, and are deleted a day after they expire — including the ones nobody ever types back, which is what an abandoned form leaves behind. Text messages are sent through Twilio, which receives the number and the code and nothing else — no name, no licence, nothing else from the form. Iranian numbers are verified over Telegram instead, because text messages to Iran do not arrive: our bot asks you to share your contact, and Telegram supplies the number attached to your account. Either way the number is proved before the registration is created; the two routes differ only in which company carries the message. Telegram sees the conversation with our bot, as it sees every conversation on it. From the verification itself we keep nothing except the same phone number you were already giving us — not your Telegram name, not your username, not the account it came from.
If the address or number you enter is already on file with us, we say so and point you at the feedback form rather than sending a code. It saves you waiting for something that cannot complete, and it means we never tell you why a registration exists — approved, declined or still under review are indistinguishable from outside. We check each registration by hand before an account is opened. Kept while your registration stands; rejected or withdrawn registrations are deleted after 12 months.
Portal and admin accounts. Email, a password hash (argon2id — we cannot see your password), optional two-factor secret, and session records. Kept while the account exists.
A doctor's encryption keys. Reports reach a doctor end-to-end encrypted (described below), so each doctor has a key pair, made in their own browser. We store the public half and its short fingerprint — the fingerprint is printed on the doctor's QR card, which is how a patient's app knows it is encrypting to the right person. The private half is stored only in encrypted form, locked twice: once with a passphrase the doctor chooses and once with a recovery key shown to them a single time. We never receive the passphrase or the recovery key and cannot open the private key — which also means that if a doctor loses both, nobody, including us, can open the reports encrypted to them. A key the doctor has replaced is kept, still locked, only while a stored report or a patient's link still depends on it, and then deleted.
The doctor's public card. Someone who scans a doctor's QR code, or opens the link printed under it, sees that doctor's name, specialty and workplace, so that they can check they are linking to the right person before anything is sent.
Doctor profile details. A doctor with a portal account can add the information they would publish anyway, so that patients can find them and check them for themselves: an office address, opening hours, a link to their entry in an official register of medical professionals, up to five links to pages of their own, and a photograph. A photograph is looked at by us before it could ever be shown publicly, and we can remove one; if we do, the doctor is told by email and can upload another. None of it is published yet — the public card shows only name, specialty and workplace, so today these profile details are visible only to the doctor themselves and to our team. Before a photograph is stored, it is copied afresh on a separate, isolated part of our server that has no access to anything else: what we keep is a new image made from the picture itself, without the details a camera or phone writes into the file, such as where and when it was taken. The file as uploaded is not kept. The photograph is stored on our own server, is served to nobody else, and is deleted when the doctor removes it and when the account is deleted, along with the rest of that account's data. Only a register's own website is accepted in the register field: a link the doctor controls proves nothing, and presenting one as verification would leave a patient with less protection than showing nothing at all. We also open that listing and check that it is about the doctor who gave it to us, and record the date somebody did; accepting the web address alone would only show that the link points at a register, not that the entry behind it belongs to them. We can remove a listing the same way we can remove a photograph, and the doctor is told by email if we do. The other links a doctor adds are not checked by us — we show them as their own pages and nothing more, because the page behind any address can change after anybody has looked at it. This notice will be updated before any of these details are shown publicly.
How we reach our own team. A member of our team can ask to be told when a registration or a piece of feedback arrives, so that nobody waits days for an answer. To do that we store what they choose: the address they sign in with is always available, and they may add a phone number or connect a Telegram chat. Each is proved with a code before anything is sent to it, so a mistyped number never begins receiving our messages. What we send is a pointer and never a payload — "new feedback, category: question" and a link to our console. Never what somebody wrote to us, never a doctor's name or address, never anything out of an error report. Text messages go through Twilio and chat messages through Telegram, exactly as described above, which is possible only because nothing in them is about anyone's health. We keep a record of each message we send — the destination, the channel and whether it went — for 90 days, so that a failure is visible instead of silent. Removing a destination deletes it; deleting the account deletes all of it.
Error reports from the app. If the SALUNOTE app breaks it can send us a
technical error report — but only after showing that person the exact report
and asking them, separately for each report. What arrives is the error type,
its message with every digit replaced by #, the place in the app's own
code, the names of the screens visited beforehand, the app version, the
operating system, the language, and anything the person chose to write. It
contains no health information, and no name, email address, phone number or
device identifier; the sending IP address is not stored. It does carry the
app's pseudonymous patient code, so that several reports from one person are
recognisable as one fault — that makes it personal data, and it is deleted
three months after the fault has been dealt with, twelve months at the outside.
Where a report describes a fault we have to fix, an administrator may copy its
technical contents into our own private issue tracker so the fix can be
followed through.
Reports a patient sends to their doctor — end-to-end encrypted. A patient can link the SALUNOTE app to a doctor by scanning that doctor's QR code, and then send that doctor their summary report. Nothing is ever sent automatically: each report is sent by a deliberate act of the patient, to a doctor they choose, and the app shows them the report before it goes.
The report is encrypted on the patient's phone to that one doctor's key and signed, and it stays encrypted on this server. We cannot read it, and neither can anyone with access to our server or its backups; only the doctor can open it, in their own browser, with their passphrase. What this site does hold, and why:
- the link: a label the patient's app chose (a pseudonym, never a name), the public keys the app made for this one link, which doctor it is with, a scrambled copy of a secret only the app knows, and when the link was made, last used and ended — so that only that app can send on it, and either side can end it;
- each report, sealed, with what it takes to deliver it: which link, which way it travels, its size, a format version number, when it was sent and whether the doctor has opened it.
None of this contains health information in a form we can read. It is still personal data — a doctor and a pseudonymous patient label, joined by dates — so it is kept only as long as set out here:
| What | Kept until |
|---|---|
| A report | 12 months after it was sent, or until the doctor deletes it |
| A report not yet opened when the link ends | deleted at once, with the link |
| An ended link | 90 days, for the security record; its secret is erased the moment it ends |
| A plan | 30 days after it was sent, whether or not the patient's phone collected it |
| A plan not yet collected when the link ends | deleted at once, with the link |
| A doctor's own foods, movements, libraries and templates | until the doctor deletes them, or the account |
Ending a link. The patient can unlink a doctor in the app at any time, and the doctor can disconnect a patient in the portal; either way the app is told, and any report the doctor had not yet opened is withdrawn. A report the doctor has already opened stays with them, as a document handed over on paper would.
What the doctor does with an opened report is the doctor's. If they print it or save it as a PDF — which happens in their browser, with nothing sent back to us — that copy is theirs, under their own professional and data-protection obligations, and outside this site.
Sharing outside SALUNOTE is the patient's own business. The app can export the same summary as a file; where a patient sends that file is their choice and does not involve us at all.
Telling a doctor a report has arrived. A doctor can choose to be told, by email and — if they add and prove them — by text message or Telegram. We store the phone number or Telegram chat they attach until they remove it, and a record of each message (destination, channel, whether it went) for 90 days. The message says only that a new report is in your inbox, with a link: never the patient's label, never anything from the report, which we could not include even by mistake. At most one such message per channel every half hour. Text messages go through Twilio and Telegram messages through Telegram, exactly as described above.
Plans a doctor sends to a patient — end-to-end encrypted. A doctor can write a diet and movement plan in the portal — meals with foods and amounts, movements with sets, repetitions or time, notes, and, if they choose, their own daily figures for energy, protein and carbohydrate and how they arrived at them — and send it to a patient who linked to them. The plan is put together in the doctor's own browser, checked there against the app's own rules for a plan (diet and movement only — nothing about medicines or doses), and then encrypted in the browser to the key that patient's app made for the link, and signed. We cannot read it, and neither can anyone with access to our server or its backups. What this site holds is the same as for a report, in the other direction: the sealed plan, which link it is for, its size, a format version number, when it was sent, and whether the patient's phone has collected it. It is kept for 30 days from sending, collected or not, and then deleted. Until the phone collects it, the doctor can withdraw it; once collected it is on the patient's phone and is theirs. If the link ends first, a plan not yet collected is deleted with it. Each movement in a plan may carry a published figure for how much energy that kind of movement takes, which the portal adds from its own table; the patient's app uses it only to print an estimate in the patient's own summary. Whether a patient follows a plan, and how it is shown to them, is described in the app's own policy: nothing is followed unless the patient chooses to.
A doctor's own foods, movements, libraries and plan templates. A doctor can add foods and movements of their own, group them into named libraries, and save a plan as a template to start the next one from. These are the doctor's own working material, not data about any patient: a template carries no patient, no dates and no author. They are stored on our server without end-to-end encryption — so that the portal can search them — and are shown to nobody but that doctor. They pass the same content rules as a plan when saved. They are kept until the doctor deletes them, and are deleted with the account.
Working out figures from a report — nothing is kept. When a doctor opens a report, the portal can do standard, published calculations with it — body mass index, an energy estimate, a protein figure per kilogram and similar, each named on screen with its source. This happens entirely in the doctor's browser: the portal may offer the latest weight, waist measurement and sex from the opened report, uses none of them until the doctor confirms it, and sends nothing back to us. Nothing typed or calculated there is stored anywhere, and closing the report clears it. The figures the doctor carries into a plan become part of that plan, as described above.
App sign-up verification — not in use. The app has no account and no sign-up — linking to a doctor needs neither — so no sign-up codes are issued or processed.
Feedback. Your message, its category, optional app version/platform, and — only if you choose to give it — an email address for a reply. Used for nothing else.
Feedback sent to our Telegram bot. You can also write to the bot directly and it reaches the same people. Two things follow from that, and they are the reason this paragraph exists. Telegram carries what you write, as it carries everything else sent through it — if that matters to you, the form on this site does not involve them. And we store the identifier of your chat with the bot alongside your message, for one purpose: so that somebody can answer you. It is kept with the message and deleted with it, on the same schedule as any other feedback, and it is the only Telegram identifier we hold anywhere.
A reply, if there is one, comes from the bot rather than from a person's own account. Nobody here can answer a question about your own care — not by Telegram, not by email, not at all. The bot will say so, and so will we: for anything about your dose, your symptoms or your medication, ask your doctor or your pharmacist.
Audit log. Security-relevant events (sign-ins, approvals, links made and ended, reports sent, a report's first opening, plans sent and withdrawn, a doctor's own items and templates created, changed or deleted, deletions) are recorded with pseudonymous identifiers — the audit log is designed to contain no names, no email addresses and no patient labels.
Cookies
Two strictly necessary cookies, both first-party and neither used to identify
you: a session cookie for signed-in portal/admin users, and a language
cookie (NEXT_LOCALE) that remembers whether you are reading the site in
English or Persian. No analytics cookies, no advertising, no tracking, no
third-party requests — every asset on this site is served by us.
Your rights
You can request access to, correction of, or deletion of your data (FADP / GDPR rights) at the contact address above. Doctors can delete individual reports directly in the portal; deleting an account removes its data — links, reports, plans, keys and the doctor's own items and templates included — unless a legal obligation requires longer retention.
If you are a patient, we do not know who you are: your link carries only a label your app chose. The quickest way to exercise your rights is in the app — unlinking withdraws every report your doctor has not opened and ends the link. For a report your doctor has already opened, ask your doctor, who holds it. You can also write to us; because we cannot tell which link is yours, we may ask you to send us, from your app, the label and the date of the link concerned. A plan your doctor sent you is on your phone once it has been collected; you can delete it there.
Changes
Material changes to this notice are published here before they take effect.