Privacy policy — “Carnet”

This page reproduces the English courtesy translation of the privacy policy, regenerated from its source at each release. The French version prevails. Version of the app online: v1.5.1 (deployed on 11.10.2026).

Courtesy translation. The French version prevails. This text is an English translation of the French privacy policy, version 2026-10-12, provided for information only. Only the French original is authoritative (“Politique de confidentialité”); in the event of any discrepancy or difference of interpretation, the French version prevails. Swiss statutes are cited by their official abbreviations; their English titles (FADP, DPO, CO, SCC…) are non-official translations, English not being an official language of the Swiss Confederation. Pages marked “in French” exist in French only.

This policy describes what the software ACTUALLY does, as it stands on the date given below. It is kept up to date with every change to the product: when the software changes, this text changes in the same release.

Publisher / party responsible for this policy David Lambrecht, sole proprietorship (individual business) not entered in the commercial register, UID (business identification number) CHE-457.668.373, Rue du Bourg 55, 3960 Sierre (Canton of Valais), Switzerland. Data protection contact: — telephone: +41 77 276 96 99. The publisher is established in Switzerland: the appointment of a representative in Switzerland within the meaning of Art. 14 FADP, which concerns only controllers whose registered office or domicile is abroad, does not apply.

Person in charge of the protection of personal information (Quebec, s. 3.1 of the Act respecting the protection of personal information in the private sector, CQLR c. P-39.1): David Lambrecht, publisher, the person exercising the highest authority within the enterprise — , +41 77 276 96 99, Rue du Bourg 55, 3960 Sierre, Switzerland.

Sales outside Switzerland. Outside Switzerland, the managed service is sold by Paddle.com Market Limited, official reseller, in the countries that the pricing page (in French) states are open. You pay by card, in Paddle's payment form, which Paddle's payment module (Paddle.js) displays on the page carnet.health/paiement/; Paddle itself collects your payment data; the publisher sends Paddle only the opaque identifier of your sync account (section 5.3). In Switzerland, the publisher sells directly, by QR invoice. In France, the managed service is not sold (5.3).

Version: 2026-10-12, in force since 12 October 2026 (replaces earlier versions, including 2026-10-11, 2026-10-10, 2026-10-09, 2026-10-08, 2026-10-03, 2026-09-28, 2026-09-24c, 2026-09-24b, 2026-09-24, 2026-09-23c, 2026-09-23b, 2026-09-23, 2026-09-10, 2026-09-09, 2026-08-20 and 2026-08-07). Governing law: Swiss law (FADP, SR 235.1; DPO, SR 235.11).

GDPR. The publisher is established in Switzerland. It offers the managed service to professionals who practise in the countries of the European Economic Area (European Union, Iceland, Liechtenstein, Norway) that the pricing page states are open: Regulation (EU) 2016/679 (GDPR) therefore applies to the processing linked to that offer (Art. 3(2)(a) GDPR), and, in the United Kingdom, the GDPR as retained in UK law. Section 8 bis gathers what these texts require us to tell you. The publisher has not appointed a representative in the Union within the meaning of Art. 27 GDPR (nor in the United Kingdom): contact the publisher directly (section 13.1).

Argentina, Chile, Panama, Uruguay. The publisher also offers the managed service to professionals who practise in Argentina, Chile, Panama and Uruguay. For the processing linked to this offer, it applies, within their scope, Argentine Law 25.326 on the protection of personal data; Chilean Law 19.628 and, from its entry into force, Chilean Law 21.719, which also applies to a controller established abroad that offers services to persons located in Chile (Art. 1 bis); Uruguayan Law 18.331, which applies in particular to a foreign controller that offers services to inhabitants of Uruguay (Law 19.670, Art. 37); and Panamanian Law 81 of 2019. Section 8 ter gathers what these laws require us to tell you.

What this version adds: it states that it is no longer possible to add a recovery contact; a contact already designated remains revocable (section 4.4). Nothing else changes.

What the version of 11 October 2026 added: invoicing under tariff 334, as tiers payant (the insurer pays the provider directly), of care covered by accident insurance (LAA), invalidity insurance (AI) or military insurance (AM): the invoice goes to the insurer of the case with the accident claim number or the AI decision number, each on its own legal basis, and the patient receives a copy of it under the AI, as under the LAMal (sections 2.1, 3, 4.3, 5.1 and 5.2); it also states that the transmission of the invoice to MediData is governed by MediData's terms of use (section 5.2). It changed nothing else.

What the version of 9 October 2026 added: the sale of the managed service outside Switzerland by Paddle, official reseller (sections 1.5, 2.2, 3 and 5.3), with the payment page carnet.health/paiement/, the only page of Carnet that loads a third-party script (2.4, 5.3, 12.1); the GDPR information for professionals in the European Economic Area and the United Kingdom (section 8 bis), and the information required by the laws of Argentina, Chile, Panama and Uruguay (section 8 ter); exit from the contract and certified erasure as they are coded (7.5, 7.6); the readable journal and the file of your account metadata (8.2). It changed nothing for Switzerland.

In one paragraph (the essentials)

“Carnet” is a progressive web app (PWA) for keeping the nursing record and invoicing, for self-employed healthcare professionals. It is built on a “zero-knowledge” architecture: your entire record is encrypted on your device, with keys derived from your secrets alone (password, recovery key, possibly biometrics). The publisher has no access to the data in clear — it can neither read it nor reset your password; the only possible recovery goes through YOUR secrets (recovery key, or Recovery Sheet recombined on your device), never through the publisher alone. The sync service, which is optional, holds only opaque encrypted blocks and an opaque account identifier. There is no tracking, no advertising and no resale of data; the application loads no third-party script, nor does the website, with the sole exception of the payment page carnet.health/paiement/, which loads Paddle's payment module (section 5.3). It is the opposite of a usual privacy policy: we “collect” almost nothing, because technically we cannot. This policy nevertheless describes honestly what remains visible (technical metadata), the limits of the model, and the only document that leaves your device unencrypted because the law requires it: the invoice intended for the insurer — the health insurer (LAMal) or, under tariff 334 as tiers payant, the insurer of an accident, invalidity or military insurance case (section 5.2).

Outside Switzerland, you buy the managed service from Paddle, a reseller (“merchant of record”) that collects the price, levies your country's tax and gives you the receipt. Your payment details are collected by Paddle, in its payment form (displayed on the page carnet.health/paiement/ by Paddle's module) and under its own responsibility. The publisher sends Paddle only the opaque identifier of your account, and enters in its register only that identifier, the date, the amount, the currency, the period paid, the payment method, Paddle's transaction or adjustment identifier and, where applicable, the reason for a refund — never your name, your email, your address or your IP address (section 5.3). Paddle sees nothing of your record.

1. Who is responsible for what — and the zero-knowledge design

1.1 You are the controller of your patients' data. As a healthcare professional, it is you who determine the purposes and means of processing your patients' data; you are its controller within the meaning of Art. 5 let. j FADP, and you remain bound by professional confidentiality (Art. 321 SCC). The publisher does not define these purposes and does not access this data.

1.2 The publisher is, at most, a technical processor of encrypted blocks. For the sync and backup-retention service alone, the publisher acts as a processor (Art. 5 let. k and Art. 9 FADP), exclusively on end-to-end encrypted blocks that it cannot decrypt. This characterisation is adopted as a precaution: by design, the publisher has no access to health data in clear or to patients' identities. The terms of this processing are governed by the contract (data processing agreement / DPA incorporated in the contract, https://carnet.health/conditions.html, in French, section 9, and the annex “List of processors” — see section 5).

1.3 The publisher is an independent controller for its own technical data only. For the metadata that belongs to it (see section 2) and for the contractual relationship with you, the publisher acts as an independent controller. This processing is lawful because it complies with the principles of the FADP (Art. 6 and 8); where necessary, it is covered by the justifications of Art. 31 FADP — processing in direct connection with the performance of the contract you conclude with the publisher, the data processed being that of the contracting party (Art. 31 para. 2 let. a FADP), and an overriding private interest in the security and availability of the system (Art. 31 para. 1 FADP). This data includes no patient data.

1.4 Local use without sync. “Carnet” works offline first: you can use it entirely on your device, without enabling sync. In that case, no data leaves your device for the publisher — except the invoices that you decide to send to insurers yourself (section 5.2). The publisher then processes, as regards you, only any subscription billing details (if you are a subscriber).

1.5 Paddle, reseller outside Switzerland: an independent controller. When the managed service is sold to you outside Switzerland, you do not buy it from the publisher but from Paddle, which resells it in its own name (section 5.3). For the data you give it when you pay, Paddle is the controller, independently of the publisher: their contracts provide for this (Paddle's seller agreement, clause 14.2, and its data sharing addendum, read on 23.09.2026). Paddle is not a processor of the publisher: it processes nothing on the publisher's behalf, and receives neither encrypted blocks nor patient data. Nor is it yours. What it does with your data is set out in its own policy: https://www.paddle.com/legal/privacy.

2. What data is processed

2.1 On your device (under your sole control, encrypted at rest)

Three families of data, all created and held by you on your device, are stored encrypted in the browser's local database (IndexedDB “carnet-v2”, via Dexie; tables ops = event log, meta = settings, medias = encrypted photos and documents: documents filed in the patient's folder and, since 16 September 2026, the copy of each document you mark as sent):

• Patients' nominative identity (internal op patient.identite): first name, surname, date of birth, sex, AVS number (format 756.xxxx.xxxx.xx, required for invoicing the insurer), insurance card number, accident claim number (LAA), AI decision number or case number (AM) of an insurance case, street of residence, insurer (GLN + name), the patient's telephone, email and guarantor. This data is marked strictly local in the code (constant OPS_LOCALES): it is filtered out before any sending and is never carried by ordinary sync. The rest of the address travels, encrypted: the municipality, postcode (NPA), locality and medico-social centre (CMS) of attachment (op patient.domicile) travel with the record, end-to-end encrypted like it, so that your other devices can prepare the rounds and the statement of the residual financing borne by the canton; the server cannot read them. They can leave the device only through the channels exhaustively described in section 4.3 (four sealed channels, unreadable for the publisher and for the server) and through the invoice intended for the insurer, which leaves unencrypted (section 5.2).
• Clinical data: care notes and handover notes, wounds (TIME method), wound photographs (encrypted in the medias table, outside the log), documents in the patient's folder (filed documents and the copy of each document marked as sent — OPAS 7 declaration, care transfer record, letter — encrypted in the same way), readings and measurement thresholds, assessment scales, suicide risk assessment (RUD), schedule and rounds, medical orders under OPAS art. 7.
• Invoicing data: OPAS 7 medical orders, invoices under compulsory health insurance (AOS) (including the LiMA material lines of invoices already issued), residual financing statements for the CMS, services and material invoiced directly to the patient (outside AOS). Acknowledgements received from insurers (facturation.accuse, opas7.accuse) are kept locally because an acknowledgement may cite the patient's name.

Relatives and emergency contacts. A patient's record may contain the contact details of relatives and contacts (healthcare representative, person to notify, neighbour who holds a key…), recorded by the nurse for the continuity and safety of care. This data lives in the encrypted record, covered by professional confidentiality, and is deleted with it; it is neither synchronised in clear nor exported to an address book. The data subjects are not informed individually: the nurse, a private person bound by a statutory duty of confidentiality (Art. 321 SCC), is released from the duty to provide information of Art. 19 FADP by Art. 20 para. 1 let. c FADP — this notice serves as general information.

No real patient data is used for demonstration: the application offers an ephemeral demo mode with pseudonyms, whose data is not kept.

2.2 What the publisher actually sees (if sync is enabled)

What the publisher can technically see is limited to the following.

2.3 What the publisher does not see (technically impossible): the content of the record, patients' identities, health data, doses, documents, wounds, readings, drafts — none of this reaches the publisher in clear, neither through sync nor through the sealed channels of section 4.3. The invoice intended for the insurer is an exception to the principle “nothing leaves in clear”: it contains nominative data in clear (section 5.2); its transmission to MediData is governed by MediData's terms of use, which you have accepted.

2.4 No tracking, no third-party audience measurement, no advertising. “Carnet” loads no third-party script, font, image or external tracker: a strict content security policy (CSP) blocks at run time any request to a third-party host: the application can reach only the sync server of its edition and, on your own computer, the connector for sending invoices. There is no advertising network, no behavioural analytics and no resale of data. One single exception, outside the application: the website's payment page https://carnet.health/paiement/, opened by the payment link that the publisher sends you for a purchase outside Switzerland, loads Paddle's payment module (Paddle.js, served by paddle.com) to display Paddle's form; its content security policy opens only Paddle's addresses. It is the only page of Carnet that loads a third-party script; the application loads none, and neither does the rest of the website. What you enter there goes to Paddle, the seller, and what Paddle stores on or reads from your device is governed by its policy (5.3).

3. Purposes of the processing and what it rests on

Swiss law does not make private processing conditional on a “legal basis”, unlike the European regulation: processing is lawful as long as it complies with the principles of the FADP (lawfulness, good faith, proportionality, recognisable purpose, accuracy, security — Art. 6 and 8 FADP). A justification comes into play only if the processing breaches the privacy of the data subject (Art. 30 and 31 FADP). The table below therefore states, for each processing operation, who carries it out and what it rests on — and, where applicable, the justification reserved.

The publisher processes no patient data on its own account, and does no profiling. Four decisions are taken automatically, on a published rule: the subscription gate gives you an access code or enters your request on the waiting list, depending on the country you declare; an unpaid subscription is suspended at the end of the grace period — outside Switzerland, also a confirmed subscription whose first period has never been paid, on the due date set by the payment-link e-mail, at the earliest twenty days after it is sent —, without ever affecting your local access to your data (contract, clause 5.4; WORLD annex, M-2 let. f bis); at the end of a thirty-day trial that you have not confirmed, the managed service pauses (sync, managed backups, opening of new locum covers), without affecting your local access or a locum cover already open, and resumes as soon as you confirm (contract, clause 5.1bis let. b); and, when the terms change substantially, the sync of an account that has neither accepted nor refused the new version thirty days after it was communicated waits for your answer, without affecting the use of the application on your device (contract, clause 12.2). This fourth decision concerns only an account that has already accepted a version of the contract providing for it: it does not apply to the version that introduces it. You are informed of this here (Art. 21 para. 1 FADP). You may state your position and require the decision to be reviewed by a natural person, the publisher: (Art. 21 para. 2 FADP). The rate limiter, which slows down bursts of requests, decides nothing concerning you. At the end of a contract, the account's move into the transition period, then into read-only access, then to awaiting erasure follows the dates that the publisher has entered at your request (7.5): this is not an automated decision, it is the dated execution of yours; the erasure itself is an act of the publisher.

4. Your health data: encrypted and under your sole control

4.1 Encryption on the device. The nursing record (event log) and the photos are encrypted on your device using a random 32-byte master key (the CMK), with ChaCha20-Poly1305-IETF. The CMK is never written in clear: it lives only in RAM during an unlocked session. On disk, it exists only in “wrapped” form (itself encrypted) under several independent secrets which all open the same key:

• your password (derived with Argon2id, MODERATE cost for new accounts; minimum of 12 characters + a local strength estimator that refuses weak passwords; passphrase recommended);
• a recovery key / recovery phrase (8 words, ~88 bits of entropy);
• where applicable, a biometric key (the device's biometrics, face or fingerprint, via WebAuthn) — this envelope remains bound to the device's hardware and is never synchronised or exported;
• where applicable, a separate custodian code.

Without one of these secrets, the local data is unreadable (the encrypted blocks alone are not enough). The publisher holds no key enabling it, alone or with the server, to decrypt your data — no administrator password, no backdoor.

4.2 Persistence and locking. The application requests persistent storage (navigator.storage.persist) to prevent certain browsers from purging the database automatically, since a nursing record is meant to be kept for many years. An automatic lock (adjustable delay) closes the vault after inactivity; drafts in progress are encrypted.

4.3 Through which channels patients' nominative identity leaves — and does not leave. Ordinary sync NEVER carries nominative identities (op patient.identite: surname, first name, date of birth, AVS number, street of residence, insurer, accident claim number (LAA), AI decision number or case number (AM); the municipality, the postcode and the locality, for their part, travel encrypted with the record — section 2.1): they are filtered out before any sending. They can leave your device through four sealed channels, which you trigger or enable, and which remain opaque to the publisher as well as to the server:

• ① Device-to-device transfer that YOU trigger (e.g. when pairing a second device): the identities travel in a sealed mailbox (crypto_box_seal, libsodium), with human verification by 4 words (anti-interception SAS). The server relays only blocks that it can neither read nor forge (it never knows the devices' public keys).
• ② DOUBLE-SEALED recovery envelope, stored on the server if — and only if — you turn on account recovery (an express choice offered when sync is enabled, revocable at any time): the identities are encrypted (AEAD under the CMK) then sealed again (box_seal) to a recovery public key. They can be opened only by combining several secrets held separately, and only on the client side, on the day of a recovery (see 4.4).
• ③ Locum cover: the transmission, to a locum nurse whom YOU designate, of the record of the patients concerned only — their entire record, history included —, identities included, as long as the access you grant is open (see 4.5).
• ④ Locum cover backup access envelope: so that a locum nurse can regain their access if they lose their device during the cover, the identities of the entrusted patients only are stored on the server encrypted under a key derived from their biometric passkey (which the server cannot derive). This envelope is limited to the duration of the cover (plus a short grace period), and destroyed by revocation, by the closing of the cover or by automatic expiry at the planned end of the mandate. The publisher cannot read it.

Separately, and neither sealed nor opaque: the invoice intended for the insurer leaves UNENCRYPTED. It is not a technical exception of the same kind as the four channels above: it is a statutory invoicing obligation, assumed as such — Art. 42 LAMal for health insurance; for a case invoiced under tariff 334 as tiers payant, Art. 54a LAA (accident insurance), Art. 27ter para. 1 LAI (invalidity insurance) and Art. 25a LAM (military insurance). Its exact content is set out in section 5.2. Its transmission to MediData is governed by MediData's terms of use, which you have accepted.

The rest of the record, encrypted, is replicated between your own devices.

4.4 Recovery service (mirroring the contract, clauses 9.11 and 10.8). Account recovery is never on by default: when sync is enabled, the application asks you the question and presents both branches — “Turn on account recovery” or “Do not turn it on” — with no option pre-ticked and without storing anything before your choice. It tells you at that point that the envelope stored contains your patients' identities, double-sealed: the decision belongs to the professional who is the controller; it cannot be inferred from a contract or from the consent of third parties. Refusal as well as revocation remain possible at any time in Settings. If account recovery is active, the mechanism rests on secret sharing: a share of 8 words stays on a paper Recovery Sheet held by you (never transmitted); the other share is sealed to an escrow key of the publisher kept OFF the server. Neither party alone — neither the server nor the publisher — can reconstruct the key; recombination takes place exclusively on the client side, with verification by 4 words. Confidentiality rests on the cryptographic strength of the 8-word share, never on a mere attempt counter.

Recovery contact. If you had designated one, you can revoke it; it is no longer possible to add a new one. Until it is revoked, a second sheet, given to the person of your choice, opens a third way in. The mechanism becomes 2-of-3 — the publisher's escrow share, plus either your 8 words or your contact's code. The protections on the day of recovery are identical through this route (waiting period, floor, veto, identity verification): there is no accelerated procedure. Your contact's name is recorded nowhere at the publisher's: it lives only in your vault, on your device, and the server never reveals whether a contact exists.

The release procedure follows a protective path described in the contract: a waiting period of 72 hours by default, with a 24-hour floor hard-coded that no server configuration can lower (the settings can only lengthen the waiting period); notification of your active devices, with a right of veto; an identity verification. In the event of revocation, the double-sealed envelope and the sealed share are destroyed (written confirmation on request). A recovery request is moreover the only operation of which the publisher keeps a durable trace including your connection address: every interaction with the recovery service — setup, change of the verification number, addition or revocation of a recovery contact, deactivation of the service, request, veto, delivery — is recorded with a keyed hash of your IP address (since 23 September 2026; previously the address itself) and the date in a dedicated log that nothing can modify or delete.

4.5 Locum cover: entrusting records to a locum nurse. When you arrange cover for your absence, you can open a locum cover: a colleague receives, on their device and in encrypted form, the record of the patients you designate only — the record itself, as you keep it, and not a summary —, identities included, as long as the access you grant them is open — you can extend it, limit it or revoke it at any time; it expires on the closing of the cover, on its revocation, or on its own 90 days after the planned end of the mandate where that date has been stored on the server (see 2.2) — a distant safety net, so that a forgotten mandate does not stay open without limit, never a cut-off on work in progress; a mandate without an end (a permanent pairing of two nurses) has no expiry date. This automatic expiry closes writing immediately and leaves reading open for thirty days, so that you can bring back the care of the last round; after that period, the account's blocks are deleted. This disclosure rests on the consent of your patients to the sharing of their record with the healthcare professionals involved in their care (Art. 321 no. 2 SCC; Art. 36 para. 2 LS/VS, the Valais Health Act; Art. 31 FADP), which you obtain and record in the application. What you need to know:

• What the server hosts: a sync account dedicated to the locum nurse, the compartment's encrypted seed data and, if they have enrolled a biometric passkey, the backup access envelope described in 4.3 ④. The publisher can read neither the identities nor the records transmitted: they can be decrypted only on the locum nurse's device.
• A commitment accepted in the application, before any access. Before a single name is displayed, the locum nurse must accept versioned “Terms of use of locum cover mode” (version in force: releve-8). The screen is blocking on first access: without acceptance, no access. Acceptance is given in a single step, with no box to tick and the full text in view; it is timestamped and recorded, and includes the locum nurse's declaration that they are authorised to practise. These terms cover: the basis for access — the patients' consent to the sharing, which you obtain and record; the maintenance of professional confidentiality (Art. 321 SCC); access limited to the care of the entrusted patients, as long as the access you grant is open, and the commitment to consult there only what their care requires; the fact that each of their entries is signed by a key that stays on their device — what they document is attributable to them, and no one, not even you, can write under their name; the extent of what they keep in the record of the entrusted patients — observations, focus charting, measurements and thresholds, medications given or refused, wounds and stomas (protocols and closure included), treatments, reassessments, appointments and care plan, documents filed in the folder, scales — and what remains yours: the declaration of care to the insurer (OPAS 7), which they consult and can print without being able to modify it, and the patient's admission form (identity, insurance, residence, allergies, wishes, nursing history on admission), which they do not modify from a shared record — what they observe at the bedside, they note in the record, under their own name; the fact that they neither open nor archive any record and remove neither a document from the folder nor an entry from the directory; the expiry of the access on its closing, on its revocation or 90 days after the planned end of the mandate, and the deletion of the compartment from their device; responsibility for their own documentation, which bears their name; the personal nature of the access (a key and a password of their own, a signature for each entry) and the shared nature of the mandate's record — the other locum nurses of the same mandate, invited by you, read and write the same record and are not third parties; reporting without delay any loss, theft or unauthorised access; not disclosing the records to third parties and making no copy outside Carnet; and the reminder that informing the patients is the responsibility of the primary nurse. There is no paper document to sign: the commitment is made in the application.
• You remain the controller. It is for you, as the nurse who keeps the record, to obtain and record the patients' consent to the sharing of their record, to inform the patients of a locum nurse's involvement, and to take account of any objection: the application flags it to you and records it in the patient's record, but withdraws no record in your place — the decision whether or not to entrust a record despite an objection, and its justification (in particular in an emergency), are yours, under your responsibility. The choice of the entrusted patients is yours, record by record.

5. Recipients and processors

The publisher keeps third parties to a minimum. “Carnet” uses no advertising trackers and no third-party analytics; the application (PWA) is self-contained (strict CSP, no CDN and no external resources loaded at run time). Two more recipients may be involved, which are not processors and therefore do not appear in the list under Art. 9 para. 3 FADP below: The publisher's liability insurer, if he ever takes one out (on the date of this version no insurance is in place, contract 3.5), in the event of a claim only: the client's data needed to handle it (identity, contract, correspondence). No patient data: the publisher holds none in clear. It is not a processor; this policy will be supplemented before anything is sent to an insurer. Paddle.com Market Limited, for a sale outside Switzerland: reseller, independent controller of the data you give it when you pay (1.5, 5.3). It receives from the publisher only the opaque identifier of your account and the refunds that the publisher decides. It is not a processor, and therefore does not appear in the list below.

5.1 Annex — list of processors (Art. 9 para. 3 FADP)

(List kept up to date and dated. Status as at 23 September 2026, reviewed on 11 October 2026. It is also the list of Annex IV to the standard clauses of the zone annex, for the encrypted blocks: Infomaniak and Proton Drive. The publisher's record of processing activities reproduces it.)

Technical monitoring and timestamping. Three external services receive, not record data, but operational signals — they are mentioned here because this list is meant to be exhaustive:

Any change to this list (addition / replacement of a processor) is communicated to you in accordance with the contract, with the possibility to object.

5.2 The invoice to the insurer — what actually leaves, unencrypted

This is the point where the model “nothing leaves in clear” ceases to apply, because the law requires it: the healthcare provider must give the insurer a detailed invoice and the information needed to check it. For health insurance, this is Art. 42 LAMal. For care invoiced under tariff 334, as tiers payant, to an insurance case recorded in the file, it is Art. 54a LAA for accident insurance, Art. 27ter para. 1 LAI (specified by Art. 79ter RAI) for invalidity insurance and Art. 25a LAM for military insurance. We say so plainly.

What the invoice sent to the insurer contains:

• the patient's surname, first name, date of birth, sex;
• their AVS number and their address;
• the services invoiced (tariff items, dates, quantities);
• the identity and address of the prescribing physician;
• a medical indication in FREE TEXT, of at most 350 characters;
• for an LAA, AI or AM case: the law, the accident claim number (LAA) or the AI decision number (AI, required by Art. 79ter para. 1 let. d RAI), the case number if there is one (AM), the date of the accident (LAA) or of the case (AM) and the reason for treatment (accident, illness, congenital disorder).

This medical indication is indeed clinical information in clear. It appears in the invoice because the insurer needs it to check coverage; it is written by you, under your responsibility, and you must limit it to what is necessary to check the invoice. What does not go into the invoice: the nursing record itself, notes and handover notes, wound photographs, scales and assessments, documents.

Who receives the invoice. The LAMal invoice goes to the patient's health insurer; that of an LAA case, to the accident insurer of that case; that of an AI case, to the Central Compensation Office (Centrale de compensation), to which the healthcare provider may send it by electronic data transfer (Art. 79 para. 1 RAI); that of an AM case, to Suva, to which the management of the military insurance has been transferred (Art. 81 para. 2 LAM). You must give the patient a copy of the invoice under LAMal tiers payant (Art. 42 para. 3 LAMal) and under the AI (Art. 27ter para. 1 LAI; Art. 79ter para. 4 RAI). Carnet prepares it for printing once the invoice has been sent; you hand it over or send it yourself — it passes through no server of the publisher.

Your care record remains unreadable to the publisher: it is encrypted on your device. The transmission of the invoice to MediData is governed by MediData's terms of use, which you have accepted. As you are connected "via the software partner Carnet", MediData discloses to the publisher, as to any software partner, the list of organisations connected through that partner: the name, place, customer identifier and GLN of your practice — never an invoice nor any patient data. The publisher processes these data on its own behalf (data processing agreement, section 2.3).

5.3 Paddle — the reseller of the service outside Switzerland

Who. Paddle.com Market Limited, a company registered in England and Wales under no. 08172165, 30 Old Bailey, London EC4M 7AU, United Kingdom (for sales outside Canada).

What it does. In the countries outside Switzerland that the pricing page states are open, Paddle sells you the managed service in its own name: it collects the price, levies and declares your country's tax, gives you the receipt, renews the subscription, retries a payment that fails and carries out the refunds that the publisher decides. The publisher sends you neither an invoice nor a payment request outside Switzerland. In Switzerland, Paddle plays no part.

Its role. For the data you give it when you pay, Paddle is the controller, independently of the publisher (1.5). It is not a processor (Art. 5 let. k and Art. 9 FADP). Its privacy policy governs that data: https://www.paddle.com/legal/privacy. Your rights over that data are exercised with Paddle (https://preferences.paddle.com); the publisher helps you if you ask it to.

The Carnet payment page. The payment link opens the page https://carnet.health/paiement/, published by the publisher. It is the only page of Carnet that loads a script from a third party: Paddle's payment module (Paddle.js), served by paddle.com. This module displays Paddle's payment form in a frame served by Paddle (buy.paddle.com). The page itself reads only the transaction number in its address, your browser's language and, if they exist, your display settings for the website (light or dark theme, palette), which stay in your browser; it writes nothing there and sends nothing to the publisher: it opens the transaction that the publisher has prepared, which carries only the opaque identifier of your account. When it loads the page, your browser connects to Paddle's servers, which receive, as for any web page, your IP address and technical information about your browser. What the page stores, measured on 9 October 2026 (Chromium browser, page loaded without a transaction): a single request to a third party, Paddle's module (cdn.paddle.com); in response, the server of this module, served by Cloudflare, sets a technical bot-protection cookie, __cf_bm, on the paddle.com domain, unreadable by the page (HttpOnly), for thirty minutes; nothing in the local or session storage of carnet.health, no carnet.health cookie. What Paddle's payment form then stores or reads, in its buy.paddle.com frame, once your transaction is open, has not been measured: Paddle describes it in its policy (section J, “Cookies and Similar Technologies”, read on 9 October 2026) — what serves the payment and fraud prevention. These operations serve only the payment you have requested: their basis is the performance of the contract (Art. 31 para. 2 let. a FADP; Art. 6(1)(b) GDPR); storing on or reading from your device what is strictly necessary for this service, which you have expressly requested, does not require your consent (Art. 5(3) of Directive 2002/58/EC); in Switzerland, the Telecommunications Act requires that you be informed of this processing and of its purpose — you are, here — and told that you may refuse it, which your browser settings allow, at the risk that the payment does not go through (Art. 45c let. b TCA, SR 784.10). The page is neither indexed nor linked from the rest of the website: it can be reached only through your payment link.

Who answers for this page. For the payment itself and for everything Paddle then does with your data (collection of the price, tax, receipt, renewal, fraud prevention), Paddle is the controller, independently of the publisher (1.5). For the mere loading of Paddle's module on the publisher's page and the transmission to Paddle that it causes, the publisher, which chose to integrate this module into its page in order to be paid, considers itself a joint controller with Paddle (Art. 26 GDPR; Art. 5 let. j FADP), in line with the Fashion ID judgment of the Court of Justice of the European Union (29 July 2019, C-40/17) — for these two operations only, never for what Paddle does afterwards. For you, this means: the publisher informs you here of these operations; you may exercise your rights concerning them with the publisher as well as with Paddle; the publisher receives your request, answers it as far as it is concerned and forwards it to Paddle for the rest (Art. 26(3) GDPR). The publisher and Paddle have not concluded a written arrangement on this point: the publisher assumes towards you the obligations described above and remains, for these two operations, your point of contact; Paddle alone answers for what it then does with your data.

What Paddle collects, from you. In its payment form: your name, your email, your billing address, your payment method (for a card, its data is processed only by Paddle and its payment service providers), where applicable your VAT number, your IP address and technical information about your device, in particular to prevent fraud. It is you who enter them: the publisher does not send them to Paddle.

What the publisher sends to Paddle. The opaque identifier of your sync account, in the transaction carried by your payment link — it links your payment to your account — and, where applicable, the refund of a transaction designated by its identifier. Nothing else: neither your name, nor your email, nor your record, nor an encrypted block, nor any patient data. The key used to talk to Paddle is on the publisher's workstation, in Switzerland: the sync server never talks to Paddle. Paddle knows that you have bought the managed service; it sees nothing of what you do with it.

What Paddle shows the publisher, and what the publisher keeps of it. Paddle makes available to every seller, in its seller area, what it knows about that seller's buyers (name, address, email, purchase history). The publisher cannot prevent this; it consults this data only to perform the sale, and copies none of it. Its payment register keeps only the items listed in section 2.2 (“Payment through Paddle”) — never your name, your email, your address or your IP address.

Where this data goes. Paddle.com Market Limited is in the United Kingdom, a State whose legislation ensures an adequate level of protection under Swiss law (Art. 16 para. 1 FADP; Annex 1 DPO). For a client in the European Economic Area, the United Kingdom benefits from an adequacy decision of the European Commission: Implementing Decision (EU) 2021/1772 of 28 June 2021 (OJ L 360, 11.10.2021, p. 1), amended by Implementing Decision (EU) 2025/2574 of 19 December 2025 (OJ L, 2025/2574, 23.12.2025), under which it expires on 27 December 2031, unless extended. The payment module is served from Paddle's servers (paddle.com), which uses providers of its choice to serve it. Paddle itself uses providers located throughout the world and frames its transfers according to its policy; these transfers fall under its responsibility.

Closed countries. The managed service is not sold where Paddle does not sell, nor where the law of the country forbids a nurse to entrust their patients' records to a server in Switzerland. France: hosting health data on behalf of a professional requires a certified host that stores the data in the European Union or the European Economic Area (French Public Health Code, Arts. L.1111-8 and R.1111-9-1); the application is used there locally, without sync, and no payment data is processed there. The pricing page keeps the list of closed countries and the reason for each.

Processing agreement outside Switzerland. For the encrypted blocks of your records, the publisher is your processor (1.2). In the European Economic Area, this relationship is governed by the WORLD zone annex, which incorporates the Commission's standard contractual clauses (Implementing Decision (EU) 2021/915), governed by the law of your State: this is the contract required by Art. 28 GDPR. You accept it together with the contract, when you subscribe.

6. Hosting and location

6.1 Hosting in Switzerland. The server infrastructure is a VPS at Infomaniak, in Switzerland (Debian), served by Caddy over HTTPS (Let's Encrypt certificates renewed automatically, HSTS headers). A single server hosts the service's subdomains:

• carnet.health — the website (presentation site);
• app.carnet.health — the PWA application (static build files);
• global.carnet.health — the international edition of the application, with no national module, online since 21 September 2026;
• qc.carnet.health — the Quebec edition of the application, online since 25 September 2026;
• sync.carnet.health — the “blind” sync server (Node.js, SQLite database local to the server), which stores only encrypted blocks and requires an invitation code to activate an account.

6.2 No transfer of patient data in clear outside Switzerland — for the simple reason that there is no patient data in clear on the server side. Any encrypted backups replicated outside Switzerland would be replicated only to a State with adequate protection (Art. 16 para. 1 FADP) or under a safeguard under Art. 16 para. 2 FADP, and would remain unintelligible. In fact: the server (Infomaniak) and the publisher's workstation are in Switzerland; the off-site copy is with Proton AG, a Swiss company established in Geneva, whose Drive servers are located “exclusively in Switzerland, Germany or Norway” (Proton Drive policy of 19 August 2026) — three States with adequate protection (Art. 16 para. 1 FADP). This copy is encrypted a second time there before sending. For a professional in the European Union, the EEA or the United Kingdom, the processing of their professional data in Switzerland is a transfer to a country recognised as adequate (Commission Decision 2000/518/EC, kept in force by Art. 45(9) GDPR; in the United Kingdom, Data Protection Act 2018, Schedule 21, paragraphs 4 and 5). Sales outside Switzerland add only one transmission: the opaque identifier of your account, to Paddle, in the United Kingdom, and, for the duration of a payment, what your browser sends to Paddle when it loads the payment page (5.3) — never patient data. For a professional in Argentina, Chile, Panama or Uruguay, the processing of their professional data in Switzerland rests, in Argentina, on the recognition of Switzerland as an adequate country (DNPDP provision 60-E/2016; Law 25.326, Art. 12); in Uruguay, on the same recognition (URCDP resolution 23/021 of 08.06.2021; Law 18.331, Art. 23); in Chile, from the entry into force of Law 21.719, on the contractual clauses of the WORLD annex, M-11.4 (Art. 27 of that law); in Panama, on the transfer being necessary for the performance of the contract (Law 81 of 2019, Art. 33). Their patients' encrypted blocks are hosted there on their behalf, without the publisher being able to read them.

6.3 What is isolated by country, and what is not. The Quebec edition (qc.carnet.health) has been online since 25 September 2026; the managed service is not yet sold there. Two distinct things, which we prefer to state separately:

• On your device, isolation is total. Each edition lives on its own domain, hence in a storage area that the browser strictly separates (its “origin”): the encrypted vault of one edition is inaccessible to another, and no data passes from one to the other.
• The sync server, however, is SINGLE (sync.carnet.health, Infomaniak, Geneva): it hosts the encrypted blocks of all editions in the same database. It cannot read them — it holds no key —, it never links two accounts together, and each account has access only to its own blocks. But there is no Quebec server: data synchronised from Quebec is hosted in Switzerland, in encrypted form. If a country required local hosting, a dedicated instance would be needed — we would say so before opening the service there. Since 21 September 2026, this requires no change to the software: the server address is a property of the edition, not a constant of the program, and each edition is allowed to reach only the server it declares — the browser blocks any other call. A nurse therefore cannot connect their own sync server to a published edition.

The international edition (global.carnet.health, online since 21 September 2026) follows the same rules: its vault is isolated on your device like those of the other editions, and its encrypted blocks are hosted on the same server, in Switzerland.

7. Retention period

7.1 Append-only model (event sourcing). Each write is an event added to a log; a correction or a business “deletion” is itself a new event, earlier events remaining in the log (medico-legal traceability). A nursing record is meant to be kept for many years (of the order of 10 to 20 years).

7.2 On the device (you) — retention is YOUR responsibility. You control your device. A reset or an erasure of the vault destroys the local data; without any secret (password, recovery key, biometrics), the encrypted blocks are permanently unrecoverable.

Retaining the nursing record for the entire statutory period — which depends on the canton where you practise: at least 20 years in Valais (Art. 32 LS/VS); at least 10 years from the last consultation in the Canton of Vaud (LSP VD Art. 87); at least 10 years from the last consultation, destruction after 20 years at the latest in Geneva (LS GE Art. 57); at least 10 years, destruction after 20 years at the latest in Fribourg (LSan FR Art. 59); at least 20 years in Neuchâtel (LS NE Art. 64); at least 10 years from the end of treatment in the Jura (JU ordinance 811.213 Art. 19); at least 20 years, even after cessation of activity in the Canton of Bern (LSP BE Art. 26); elsewhere, the period set by cantonal law; and 10 years for accounting records (Art. 958f CO) — is incumbent on you, the healthcare professional, and on you alone. This is not boilerplate: the publisher does not guarantee it and cannot guarantee it, since it can neither read, nor identify, nor verify the integrity of content that it is unable to decrypt. It can therefore neither certify that a record still exists, nor return it to you if you lose your secrets.

“Carnet” provides you with the tools for this retention (verified .carnet export, backups, records custodian, sync between your devices); long-term safekeeping, backup copies and their periodic checking remain yours. It is up to you to put in place a backup practice that survives the loss, theft or failure of a device, as well as the cessation of your activity.

7.3 On the server (publisher). Only encrypted blocks are kept, indexed by an opaque account identifier, for as long as your sync account exists. Transient items are single-use and short-lived: a pairing seal is valid for 10 minutes and deleted as soon as it is collected; a sealed locum cover invitation is valid for the duration you choose (from one hour until the start of the cover, 45 days at most) and its envelope is deleted as soon as it is taken, has expired or is withdrawn, or as soon as the cover is closed; a message in the identity mailbox is valid for 7 days and deleted as soon as it is collected, expired messages being purged continuously. The sync account dedicated to a locum cover and its encrypted seed data exist for the duration of the cover: its closing invalidates the server token, and the locum nurse deletes that cover from their device; their other covers and their local vault are not affected.

7.4 Backups. A daily backup of the server database, verified (opening, integrity check, presence of the data); 3 daily copies are kept on the server, the oldest being deleted at each run. A copy is also taken every day off the server, onto a medium held by the publisher, where it is purged after one year. A third copy, off site, is pushed every day from the publisher's workstation to Proton Drive (Proton AG, Geneva; servers in Switzerland, Germany or Norway) — never from the server — into an encrypted backup repository (restic), which keeps 30 daily, 12 weekly and 12 monthly copies. The rotation therefore keeps no copy older than one year. One reservation, for the off-site copy: what the rotation removes is not deleted permanently at Proton, but placed in the Proton Drive trash, where it may remain until that trash is emptied; Proton also keeps its own backups for up to 30 days. These remnants are encrypted twice and Proton holds no key that would allow it to read them. All backups contain only encrypted blocks: a stolen backup remains unreadable without the secrets you hold.

These backups serve to restore the service after an incident. They are not an archive of your record, and the publisher guarantees, through them, no long-term retention (see 7.2).

7.5 End of the contract, account deletion, right to erasure. Local erasure is immediate and under your control. On the server side, nothing is closed on a doubt: the end follows the dates that the publisher enters at your request (end date; transition period if you ask for it; immediate erasure if you ask for it), and the application shows them to you on the “Sync & devices” screen.

• Until the end date, and during a transition period of thirty days if you asked for it, the service continues unchanged, free of charge.
• Then comes read-only access for at least thirty days: your encrypted blocks remain intact, your devices can still pull them, but no longer push; no new locum cover opens; the identity mailbox stays open so that a new device can bring back the names. Reading remains open until the erasure actually takes place.
• Erasure is a tooled procedure of the publisher, carried out in a single operation: it erases the encrypted operations, the media, the account recovery facility (envelope, escrow share, telephone, double-sealed identities), the timestamping days, the pending messages, the invitation envelopes and each locum cover compartment you had opened. The server returns a receipt for it (counts, bytes, fingerprints, including the head of your log's integrity chain), and the publisher sends you a dated certificate that cites it.
• What remains, without content: your account's row (opaque identifier, “revoked” mark and dates), your acceptance receipts, the payment register, the recovery procedure log and the invitation link of locum covers, for the periods in 7.6.

A revocation alone, without the end of the contract, invalidates the access token without erasing anything. The encrypted copies then disappear from the backups as they rotate, within one year at most, subject to the reservation for the off-site copy (Proton Drive trash and remnants described in 7.4) — a backup cannot be modified item by item without losing its value as a backup. This erasure does not release you from the statutory retention of the record (7.2): export it (.carnet, and if you wish the readable journal, 8.2) before the end date.

7.6 Retention periods for the publisher's own data. The periods below concern only the data that the publisher holds in its own right (section 2.2). They are given here because the law requires them to be stated in response to an access request (Art. 25 para. 2 let. d FADP) and requires data to be destroyed as soon as it is no longer needed (Art. 6 para. 4 FADP). Each period is based on what makes it necessary; beyond it, the data is destroyed.

8. Rights of data subjects (Art. 25 et seq. FADP)

8.1 Patients exercise their rights with you, the healthcare professional. The rights of access, rectification and erasure (Art. 25 et seq. FADP) concern data that only the healthcare professional can decrypt and identify. It is therefore with you, as controller, that these rights are exercised. The publisher, having no access to the content, is not in a position to handle them and forwards without delay to the controller any request it receives by mistake.

8.2 The publisher provides the tools. To enable you to answer these requests and to remain in control of your data, “Carnet” offers in particular:

(a) the “Full patient record — right of access (Art. 25 FADP)”: a readable, printable document that can be handed to the data subject, setting out their entire record — it is this document, and this document alone, that answers an access request;

(b) the encrypted .carnet export: a backup of your whole practice, which can be read only by “Carnet” and on the account that produced it, and which contains the records of all your patients. It is neither a portability tool nor a document that can be handed to a patient — handing it to them would breach professional confidentiality towards all the others;

(c) revocation of the sync account: it permanently cuts off your devices' access to the server; the encrypted blocks already stored remain there until certified erasure, at the end of the contract or on request (7.5);

(d) local access to the entire record, at any time and without an intermediary;

(e) the readable journal (button “Export the readable journal”, Backup screen): your Carnet journal, decrypted on your device, in a JSON file that other software can read, identities included, without the photos. This file is in clear: store it as you would a paper record. It serves to change tools or to keep a readable copy without Carnet; it is not a document to hand to a patient (it contains all your records);

(f) the metadata of your account held by the server, in a JSON file: attached automatically to the readable journal, or provided on request by email. It contains neither the fingerprint of your token, nor the escrow share, nor any IP address, and names what it does not contain.

8.3 Your rights with respect to the publisher concern only the data that the publisher holds in its own right (section 2.2): billing details, payment register, account identifier, technical data. You can exercise them through the contact given at the top of this document. For the payment data that Paddle holds (5.3), contact Paddle (https://preferences.paddle.com); the publisher helps you do so.

8 bis. If you practise in the European Union, the EEA or the United Kingdom (GDPR)

8 bis.1 Who is responsible. For your professional data (subscription, account, receipts, payment register, recovery, exit), the controller is the publisher, whose identity and contact details appear at the top of this policy. For the payment data you give to Paddle, it is Paddle (1.5, 5.3). For your patients' data, it is you (section 1.1); the publisher is only your processor for the encrypted blocks, on the terms of the WORLD zone annex (5.3).

8 bis.2 Representative. The publisher has not appointed a representative in the Union (Art. 27 GDPR) or in the United Kingdom. Any request goes directly to the publisher (13.1).

8 bis.3 Record. The publisher keeps a record of processing activities (Art. 30 GDPR), for what it processes on its own account and as the processor of each client, and provides it to the supervisory authority that requests it.

8 bis.4 Legal bases. Each processing operation and its basis are set out in section 3. Under the GDPR: performance of the contract or of steps taken at your request before entering into it (Art. 6(1)(b) GDPR) — subscription, sync, payment link and payment page, exit and erasure; the publisher's legitimate interest (Art. 6(1)(f) GDPR) in the security of the service, the fight against abuse — including checking that a free trial is opened only once per Client (section 3) —, and proof of your acceptance, of your payments and of the erasure; your consent (Art. 6(1)(a) GDPR) for the sole optional answer “How did you hear about Carnet?”, which you may withdraw at any time without affecting your subscription.

8 bis.5 Your rights. You have the right to access your data, to have it rectified or erased, to have its processing restricted, to object to processing based on legitimate interest and to receive the data you provided in a structured format (Arts. 15 to 21 GDPR) — in particular through the file of your account metadata (8.2(f)). Erasure is limited by the periods in section 7.6, where data must be kept as proof or for accounting. The publisher replies within one month (Art. 12(3) GDPR), in your language if it is French, English, German, Italian or Spanish. The automated decisions listed in section 3 are necessary for the performance of the contract (Art. 22(2)(a) GDPR): you may express your point of view, contest them and obtain that a person, the publisher, reviews them ().

8 bis.6 Transfers. Your professional data is processed in Switzerland, a country recognised as adequate (6.2); the opaque identifier of your account goes to Paddle, in the United Kingdom, and, when you pay, what the payment page sends to Paddle (5.3).

8 bis.7 Complaint. You may lodge a complaint with the supervisory authority of the State of your habitual residence, your place of work or the place of the alleged infringement (Art. 77 GDPR); in the United Kingdom, with the Information Commissioner's Office. As the publisher has no establishment in the Union, no authority is “lead”. The Federal Data Protection and Information Commissioner (Switzerland) remains competent under the FADP.

8 bis.8 Your patients. Their rights are exercised with you, as in section 8.1; the tools in section 8.2 serve you in the same way.

8 ter. If you practise in Argentina, Chile, Panama or Uruguay

8 ter.1 Who is responsible. For your professional data (subscription, account, receipts, payment register, recovery, exit), the controller is the publisher, whose identity and contact details appear at the top of this policy. For the payment data you give to Paddle, it is Paddle (5.3). For your patients' data, it is you (section 1.1): these are health data, sensitive within the meaning of those laws; the publisher holds them only encrypted, without being able to read them, and hosts them on your behalf (WORLD annex, M-11.3).

8 ter.2 Contact. The publisher has no representative in any of these countries. You, your patients and the authorities can reach it at , an address it keeps up to date and operational (in Chile, the means of contact that Law 21.719 requires of a controller not domiciled there), or at the other contact details in section 13.1.

8 ter.3 What the publisher processes, and why. The processing operations and their purposes are those of section 3: performing the contract you conclude (subscription, synchronisation, payment link, exit, erasure), securing the service and the rule of a single free trial per Client, and keeping proof of your acceptance, your payments and the erasure. The publisher processes no health data in clear, sells or transfers no data, and does no profiling.

8 ter.4 Your rights, and the response time. You may request access to your data, its rectification or updating, its erasure and, where your law provides for it, object to a processing operation or obtain its portability — in particular through the file of your account metadata (8.2(f)). Erasure is limited by the periods in section 7.6, where data must be kept as proof. The publisher replies within the time limit set by the law of your country, and in your language if it is French, English, German, Italian or Spanish. Access is free of charge.

8 ter.5 Transfers. Your professional data is processed in Switzerland (6.2); the opaque identifier of your account goes to Paddle, in the United Kingdom, for the sole payment you make (5.3).

8 ter.6 Complaint. You may apply to the authority of your country named in the table in 8 ter.4. The Federal Data Protection and Information Commissioner (Switzerland) remains competent under the FADP.

8 ter.7 Your patients. Their rights are exercised with you, as in section 8.1, within the time limits of your law; the tools in section 8.2 serve you in the same way. The publisher forwards to you without delay any request it receives by mistake.

9. Data security (Art. 8 FADP, DPO SR 235.11)

The publisher implements security appropriate to the risk, in particular:

• Content encryption using the libsodium library (ChaCha20-Poly1305-IETF), with a 32-byte master key never held by the publisher;
• Key derivation with Argon2id (MODERATE cost) from your password (minimum of 12 characters + a local strength estimator that refuses weak passwords; passphrase recommended; no forced rotation — NIST SP 800-63B), for resistance to brute-force attacks;
• “Blind” server: sync handles only opaque encrypted blocks, with a neutralised operation type on the server side;
• End-to-end sealing (crypto_box_seal) of identity transfers, with human verification (4-word SAS);
• Transport encryption (TLS/HTTPS, HSTS) between your devices and the server;
• Auto-lock of the local vault and encrypted drafts;
• Access logs disabled: the servers log no requests. The IP address is used only in RAM, for the time needed to apply the rate limiter, and is never recorded — outside the recovery service, account and IP address therefore cannot be linked after the fact. The sole exception: an account recovery request, for which the (keyed) hash of the address and the date are kept as evidence against a fraudulent request (4.4);
• firewall, fail2ban, key-only SSH access (root account disabled), encrypted backups, hosting in Switzerland.

The strength of this protection depends decisively on the confidentiality of your secrets (password, recovery key), which you alone hold: keep them safely, separately and durably.

Verifiability. The code of “Carnet” is free software (AGPLv3) and is intended to be publicly auditable at https://carnet.health/source/, where the archive of each published version is deposited and verified at each release. These properties can be verified by you or by any third party of your choice.

10. Honest limits of the zero-knowledge model (metadata)

The model “the server cannot read” is real and verified by the tests: the sync server decrypts nothing; it stores and returns encrypted blocks. The key (CMK) never leaves the device; the password, the recovery key and biometrics never pass through the server. The publisher cannot read the records either (it does not have the CMK).

In all honesty, and without overpromising: zero-knowledge protects the content, not all the metadata. An operator observing the server in operation could see: the account identifier (an opaque pseudonym, not derived from patient data, but present in URL paths), the size of the blocks (e.g. telling a photo from a note), the rhythm of activity and the graph of linked devices — never the medical content, never the names. The threat model adopted is the “curious operator”: that is why the server's access logs are disabled — nothing is written, and the IP address lives only in RAM for the rate limiter: outside the recovery service, account and IP address cannot be linked after the fact. This metadata is observable only live by whoever operates the server, and cannot be reconstructed afterwards from a log — with one exception: for integrity timestamping, the server keeps, per account, the days on which the log changed (anchor table), with nothing of their content. Padding of blobs is deliberately not implemented (outside the model for hosting under our own control). Finally, the invoice sent to the insurer falls outside the zero-knowledge model: it is in clear, by statutory obligation (section 5.2).

11. Breaches of data security (Art. 24 FADP)

11.1 A leaked encrypted block cannot be exploited. In the event of an incident affecting the sync server, what could be exposed is limited to unintelligible encrypted blocks and to opaque identifiers: no patient data in clear is exposed. Such a breach is therefore, in principle, not likely to result in a high risk for the data subjects (Art. 24 para. 1 FADP). This is an honest statement, not a guarantee that nothing can ever happen.

11.2 Who notifies what. The publisher notifies the controller (you) without delay of any breach affecting the data entrusted to it. The assessment of whether it is necessary to notify the FDPIC (PFPDT/EDÖB) and the data subjects is ultimately yours (as controller), with reasonable assistance from the publisher. For the data the publisher holds in its own right, it fulfils its own notification obligations. A breach at Paddle falls to Paddle, which notifies it where the law requires; the publisher informs you as soon as it becomes aware of it.

12. Cookies and local storage

12.1 No third-party cookies, no advertising trackers. “Carnet” uses no tracking cookies, no pixels, no third-party tags — neither in the application nor on the website, pricing page included. Only the payment page carnet.health/paiement/ loads Paddle's payment module: on loading, it sets a single technical bot-protection cookie (__cf_bm, paddle.com domain, thirty minutes, measured on 9 October 2026, page loaded without a transaction); what Paddle's payment form then stores or reads serves the payment and fraud prevention, and is governed by its policy (5.3). The application uses only technical local storage on your device (IndexedDB), which it needs to work offline and to keep your vault encrypted. This data stays on your device and is not sent to the publisher in clear.

13. Contact, changes, date

13.1 Contact. For any question concerning this policy or the exercise of your rights over the data held by the publisher: , by telephone on +41 77 276 96 99, or by post to David Lambrecht, Rue du Bourg 55, 3960 Sierre (VS), Switzerland. An email address alone would not be sufficient for the formal exercise of a right of access: the postal address is therefore given here, instead of being communicated on request.

13.2 Changes. The publisher may adapt this policy to take account of technical, legal or service developments. Any change is communicated by a notice in the application or electronically. The applicable version is the one in force at the time of your use; the date and version number appear at the top of the document.

13.3 Governing law. This policy and the processing it describes are subject to Swiss law, in particular the FADP (SR 235.1) and the DPO (SR 235.11). For the processing linked to the offer of the managed service in the European Economic Area, the GDPR also applies (Art. 3(2)(a)), and, in the United Kingdom, the GDPR as retained in UK law: section 8 bis gathers the corresponding information.