1. Who we are and how to reach us
Stabli is a practice-management application for solo psychotherapists, operated by [OPERATOR LEGAL NAME], [ADDRESS], Switzerland (“Stabli”, “we”). For any question about this notice or about personal data in Stabli, write to [CONTACT EMAIL].
This notice is drafted for Swiss law only. Stabli is offered to practitioners in Switzerland; we do not direct the service at other markets, and this notice does not describe GDPR processing.
2. Two kinds of data, two controllers
Everything in the sections below depends on this distinction, so it comes first.
a. Your account data — Stabli is the controller
The data that describes you as our customer — your name, email address, sign-in credentials, settings — is processed by Stabli for its own purposes (providing and securing the service). Sections 3–5 cover this data.
b. Patient data — your therapist is the controller
The data you record about your patients — names, the contact, insurance and invoicing details you choose to keep beside them (a date of birth, an insurer, and on a prescription the physician who signed it), appointment history, prescriptions, the invoices you issue from them (and, where you send one to the insurer, the diagnosis code on the prescription it claims against), and the clinical notes you write — is health-related and therefore sensitive personal data under Art. 5 let. c FADP. For this data the therapist is the controller. Stabli acts solely as the therapist’s processor under Art. 9 FADP: we process patient data only to operate the service for that therapist, only on the documented instructions in our Data Processing Agreement, and never for our own purposes. We do not advertise to, profile, or build products from patient data.
One thing worth saying plainly, because holding an address is usually taken to imply using it: Stabli sends your patients exactly two things, and only when you ask it to. Since 6 September 2026 you may invite a patient to complete their own file from their phone. When you press Invite, the service emails that patient a link; when the patient opens it and asks, it emails them a six-digit code; and that is all. No reminder, no confirmation, no newsletter, nothing at a phone number, and nothing for a patient you never invite. Both messages name your practice and never the patient, they are carried by Resend on its European region (Section 6), and what the patient enters is recorded on their file marked as theirs. If a patient hears anything else from you, it is because you wrote to them.
Since 6 September 2026 the service also carries the report your patient’s insurer requires after thirty sessions of prescribed psychotherapy (Art. 11b OPAS). You write your part in the application; the physicians you name for it — the prescribing physician and, where the ordinance requires one, a psychiatrist — receive from the service an email with a link, naming your practice and their role and never the patient, and, when they ask from that link, a six-digit code to the same address. Behind the code they read the case sheet you prepared (the patient’s identity, insurer, prescription, the sessions held and your part, diagnosis included), write their own part and accept a declaration that is their electronic signature. Those physicians are recipients you designate, bound by their own professional secrecy; Stabli is the channel. What the service keeps about them — their name and address, what they wrote, and the evidence of their signature, including the address it verified and the IP address used — is held for you as the rest of the record is (Section 8). The signed report is filed on the patient’s record as a PDF. Stabli sends that report to nobody: it leaves only as a PDF you or the prescribing physician download and pass to the insurer’s medical adviser yourselves.
Since 11 August 2026 the service holds the clinical record itself: the notes a therapist writes about a session or about a patient’s file between sessions, and the earlier version of a note the therapist has since amended. Since 26 August 2026 a therapist may flag a note as a personal one — their own reflection, kept beside the official patient file rather than in it; a flagged note is protected exactly as any other and the flag decides nothing about a patient’s legal right of access, which turns on what a note contains. This is the most sensitive data in the product and Section 8 describes exactly how it is protected, including what that protection does not do.
One consequence is easy to miss and we would rather name it: a note often mentions people who are not the patient — a family member, an employer, another treating professional. Those people are data subjects too. We never see who they are, we do not index or analyse the text, and the therapist who wrote it decides what belongs there; but a request from such a person, like a patient’s, is answered by the therapist, not by us.
If you are a patient: your therapist, not Stabli, decides what is recorded and is your point of contact for questions, access, correction, or deletion. We support therapists in answering those requests, but we cannot answer them ourselves — we are not entitled to know who you are, and the service is engineered so that we hold as little of that answer as possible (Section 8).
3. Therapist account data we process
| DATA | PURPOSE | KEPT |
|---|---|---|
| Full name, email address | Creating and operating your account; addressing you in the product; service messages (confirmation emails, security notices). Your email address is also sent to our product-analytics sub-processor (Section 6) so that we can tell one account apart from another when we look at how the application is used. | Until account deletion |
| Password (stored only as a hash by our authentication sub-processor) | Signing you in. | Until account deletion |
| Practice settings (time zone, services and rates) | Rendering your diary correctly. | Until account deletion |
| Calendar subscriptions — one for each device you add | Letting your own calendar application read your diary. We keep the name you give the device, a one-way hash of its password (never the password itself), and when and how often it last read — so a device you do not recognise is something you can see and switch off. | Until you revoke it or delete the account |
| Technical logs (timestamps, status codes) at our hosting sub-processor | Keeping the service up and diagnosing faults. Logs do not carry patient names. | Short rotation set by the host |
We rely on the performance of our contract with you as the basis for this processing, and on our legitimate interest in keeping the service secure for the technical logs. We collect nothing about you from third parties, and nothing beyond what the table names.
4. What we never do
- No advertising, no sale of data, no sharing for marketing.
- No advertising or cross-site tracking, and no tracking scripts in your browser. Since 18 August 2026 we do measure how the application itself is used — which features get used, and by how many practices — and Section 6 names the company that receives it. That measurement happens on our server, not in your browser: nothing is loaded into the page, nothing follows you anywhere, and no cookie is set for it (see Section 9).
- Nothing about a patient in that measurement. What we send is that an action happened and which account it belonged to — never a patient’s name or identifier, never a session, a note or a prescription, and never a word of what you wrote. We do see how often you use each part of the product, because that is what the measurement is for; what nobody at the other end can see is who any of it was about.
- No automated decision-making with legal or similar effect on you or your patients.
- No use of patient data for our own purposes, including product analytics or model training. Patient data is processed only as your processor, on your instructions.
- No transmission of notes or patient identities to any external analysis or artificial-intelligence service. None of the sub-processors in Section 6 receives them. Should that ever change, it changes as a sub-processor change under Section 6 — with advance notice, a right to object, and your own patients informed — and not quietly.
5. Your rights as an account holder
Under Art. 25 ff. FADP you can ask us at any time what data we hold about you, have it corrected, receive a copy, or have your account deleted. Deleting your account removes your practice data with it — which is why the product asks you to export first, and why your cantonal duty to retain patient records (typically 10–20 years) remains yours and survives the deletion of the account. Write to [CONTACT EMAIL]; we answer within 30 days. You may also complain to the Federal Data Protection and Information Commissioner (FDPIC), Feldeggweg 1, 3003 Bern.
6. Sub-processors
Stabli runs on a deliberately short list of providers. Each is bound by a data processing agreement, and each appears in the sub-processor annex of our DPA with the notice-and-objection mechanism that governs any change to this list.
| PROVIDER | ROLE | LOCATION |
|---|---|---|
| Supabase (Supabase, Inc.) | Database and authentication. Holds the application database and the sign-in system. | AWS Zurich region, Switzerland |
| Vercel (Vercel, Inc.) | Application hosting and edge network. Runs the application code that serves each request. | USA / global edge |
| MediData (MediData AG) | Transmission of your tiers-payant invoices to insurers, on your instruction and only when you press Send. Receives, for each such invoice, the claim the insurer's system reads: the patient's identity as printed, the prescribing physician, the diagnosis code on the prescription, and the tariff lines. Receives nothing about patients you bill any other way, and no note. | Root (Lucerne), Switzerland |
| Resend (Resend, Inc.) | Delivery of five kinds of email and no sixth: the two the patient invitation sends — the invitation to complete their own file, and the six-digit code behind it — the two a physician you name receives for the thirty-session report — the link asking for their part, and the code behind it — and, since practices of several, the invitation a colleague receives to take a seat in your practice. Receives, for each message, the recipient's email address, the name of your practice as sender, and the message text, which names your practice (and, for a physician or a colleague, their role) and never a patient, and never carries a word of a report or a note. Receives nothing for patients you do not invite, physicians you do not ask or colleagues you do not seat. | European Union (Ireland) |
| PostHog (PostHog, Inc.) | Product analytics — how the application itself is used. Receives the fact that you performed an action in the product and your account email address. It receives nothing about your patients: no name, no identifier, no session, no note, and no count of any of them. | European Union (Frankfurt) |
7. Where data goes (cross-border)
The database — where patient data rests — is in Switzerland (Supabase on AWS, Zurich). No cross-border disclosure arises from storage.
Vercel operates from the USA and a global edge network, so request handling can involve disclosure to the USA. Vercel is certified under the Swiss–U.S. Data Privacy Framework, which the Federal Council recognises as providing adequate protection (Art. 16 FADP).
Resend receives the two emails of the patient invitation, the two of the thirty-session report circuit (Section 2b) and, since practices of several practitioners, the invitation a colleague receives to take a seat in your practice — the recipient’s address, your practice’s name and the message, which never names a patient and never carries a word of a report — on its European region in Ireland, an EEA state whose legislation the Federal Council recognises as adequate, so this disclosure too rests on Art. 16 para. 1 FADP. Resend, Inc. is a US company, and its own access to that region from the USA is covered by its data processing agreement.
PostHog receives the product measurement described in Section 4, on its European instance in Frankfurt, Germany. Germany is in the European Economic Area, whose legislation the Federal Council recognises as adequate, so this disclosure rests on Art. 16 para. 1 FADP directly and not on the Data Privacy Framework that the two paragraphs above depend on. No patient data is disclosed to it, so nothing in this paragraph concerns your patients.
8. How patient data is protected
Because patient data is sensitive and the people it describes have no direct relationship with us, the service is built so that protection does not depend on policy alone:
- Isolation per practice. Row-level security in the database confines every query to the signed-in therapist’s own rows; there is no cross-practice access path.
- Encryption of identity and of the clinical record. Patient identity fields, the contact details (telephone, email, postal address), the insurance and invoicing details (AVS number, date of birth, insurer and insured number) you record beside them, the copy of that identity an issued invoice keeps, the prescribing physician’s name and GLN on a prescription, the thirty-session report’s parts (yours, and what each physician wrote) together with the physicians’ names and addresses, and note text (including superseded versions of an amended note) are encrypted at the application layer (AES-256-GCM) with a key held by the application, not the database — so the database and its backups never hold a readable patient identity, a readable address, or a readable note. The insurance number is never indexed and is never used to look a patient up, because an identifier a person carries for life is the one value a leak would let anyone join to any other record of them.
- Swiss hosting. The database and the authentication system both run in the AWS Zurich region.
- Minimised sharing.A calendar application you subscribe to your diary receives appointment times and nothing else that describes a patient: every event is titled “Consultation” — one fixed word, the same on every event, in the language you work in — and carries a link back to the patient’s record here, which opens only for the signed-in therapist. No name, and no part of one — not initials — ever leaves in a calendar event. Nothing here can be read without a credential: a subscription answers only to a password issued for one device, which you can revoke on its own and whose reads you can see. Where you point that calendar application is your disclosure to make, and it is the only way a diary leaves this service at all.
- Transport encryption for every connection, and encryption at rest at the database host.
- Confidentiality chain. Psychotherapists are bound by professional secrecy (Art. 321 of the Swiss Criminal Code). Stabli acts as the therapist’s auxiliary within that secrecy, and everyone who works on Stabli signs a written confidentiality undertaking (Art. 62 FADP).
What this protection does not do. The key that opens all of the above is held by the running application, which means Stabli — a small number of named people with production access — is technically capable of reading your patients’ notes. We say so plainly rather than implying a guarantee the architecture does not give. What stands around that capability is: written confidentiality undertakings inside your Art. 321 SCC secrecy, access only where operating the service requires it, an audit log that records reads of a patient’s notes, no processing of that content for any purpose of ours, and no disclosure to anyone except under a legally binding Swiss order — which we tell you about unless the law forbids it, and challenge where we consider it unlawful. This is the same trust boundary that has always applied to your patients’ names; notes make it matter more, so it is stated here rather than left to be inferred.
9. Cookies
Stabli sets only the authentication cookies needed to keep you signed in between requests and between visits — and, in the browser of a patient completing their file through an invitation, one cookie holding the hour their verification code bought, which is gone with their save — and likewise, in the browser of a physician signing a thirty-session report, one cookie holding the hour their code bought, scoped to that page. They are strictly necessary for the service to function, are not used for tracking, and persist until you sign out or they expire. There are no analytics cookies, no advertising cookies, and no third-party trackers — so there is no cookie banner, because there is nothing to consent to. The product measurement described in Section 4 does not change this and is the reason the sentence is worth spelling out: it is performed by our own server after your page has been sent, so no analytics code runs in your browser, nothing is stored on your device for it, and there is no identifier that could follow you to another site.
10. Changes to this notice
When this notice changes in substance we will publish the new version here with a new version date and inform account holders by email. The version you are reading is identified at the top of the page.