Where Should Therapists and Health Professionals Store Patient Notes? (Medical Secrecy + GDPR, 2026)

You finish a session, you write up your notes, and then comes the quiet question nobody trained you for: where do these actually live? On your laptop? In a Google Doc? In the practice-management app a colleague recommended? For most health professionals and therapists, patient notes are the single most sensitive thing they handle, and the storage decision is usually made by accident, whatever was easiest the day the caseload got heavy.

This article answers the practical question directly: where can you store patient notes so that you respect both medical secrecy and the GDPR, without pretending any single tool makes you "compliant" on its own. It is written for solo therapists, psychologists, physiotherapists, small practices, and any clinician who keeps case notes outside a hospital's IT department. It is not legal advice, and where the law is specific I will point you to the principle rather than invent a citation.

Quick answer

Store patient notes so that the file is unreadable to anyone but you, and so that no third party can read it even when it sits on their servers. In practice that means one of three routes: keep the notes on your own device with strong encryption and disciplined backups; use a certified health-data host (in France, an Hebergeur de Donnees de Sante, HDS); or use a zero-knowledge encrypted tool where the provider only ever holds ciphertext. Ordinary consumer cloud (Google Drive, Dropbox, a plain Notion workspace) is a poor fit, because the provider can technically read the data and is rarely contracted or certified for health records. Medical secrecy and GDPR are two separate obligations that both apply, and no product certifies you: your whole process does.

Why this weighs on you specifically

A clinician's notes are not ordinary documents. Under French law, patient information is covered by medical secrecy (secret medical), a professional-secrecy duty rooted in the Code de la sante publique and backed by criminal penalties in the Code penal for its breach. You do not need to remember the article numbers to feel the weight: disclosing identifiable patient information, even by negligence, is not merely a data incident, it can be a professional and criminal matter.

On top of that sits the GDPR. Health data is a "special category" of personal data, which the regulation treats with heightened protection: processing it is restricted by default and demands appropriate safeguards. The GDPR also requires security measures "appropriate to the risk," and explicitly names encryption as one such measure. So you are carrying two obligations at once. Medical secrecy says who may know. GDPR says how the data must be protected, for how long, and what happens if it leaks. A convenient tool can satisfy neither if it quietly makes your case notes readable to a company you never vetted.

The risk is not abstract. A lost or stolen laptop, a reused password, a misconfigured shared drive, a subcontractor breach at your cloud provider: any of these can turn a private note into an exposed one. When the underlying document is readable, exposure means the content is out. That is the exact scenario worth designing against, and it is why the encryption model matters more than the brand name on the app.

The real question: who can read the file?

Most storage confusion disappears once you stop asking "is it encrypted?" and start asking "who holds the keys?" Almost every serious service encrypts data at rest. The decisive difference is whether the provider can decrypt it.

There are three broad models, and it is worth being honest about where each one leaves you.

Storage model	Who can read the notes	Fit for patient records
Consumer cloud (Google Drive, Dropbox, plain Notion)	The provider can, and holds the keys	Poor. Rarely contracted or certified for health data; provider-readable
Certified health host (HDS in France)	The host, under a strict legal and technical framework	Good, and sometimes required, but heavier and usually paid
Zero-knowledge / client-side encryption	Only you; the provider stores opaque ciphertext	Strong for confidentiality; you carry key-recovery responsibility
Local-first, encrypted on your own device	Only you, offline	Strong for confidentiality and sovereignty; you own backups

The difference between the first row and the last two is the whole game. In a breach, a provider-readable store leaks readable documents, while a client-side-encrypted store leaks unreadable noise. That contrast is worth understanding in detail, because it is exactly what changes your exposure when something goes wrong. I wrote a full breakdown of what actually changes when encrypted-at-rest data leaks versus locally encrypted data, and the short version is: encryption at rest protects the provider's disks, client-side encryption protects you from the provider.

A quick vocabulary note, because the marketing terms blur together. "End-to-end encrypted" and "zero-knowledge" are related but not identical, and the distinction matters when you are picking a tool for regulated data. If you want the precise version, see end-to-end versus zero-knowledge encryption. For notes at rest, the property you want is zero-knowledge: the service hosting your data cannot read it, even if it is hacked or compelled to hand it over.

A word on HDS, and where it does and does not apply

In France, when a third party hosts identifiable health data on your behalf, that host generally needs HDS certification (hebergement de donnees de sante), a framework anchored in the Code de la sante publique. This is a common blind spot: a therapist stores case files on a generic cloud that is not HDS-certified, assuming "it is encrypted" is enough. It usually is not, for hosted health data.

But here is the nuance that changes the calculus. HDS governs hosting by a third party. If the data never leaves your own device, or if it only ever reaches a provider as ciphertext the provider cannot decrypt, the picture shifts. Certification is designed to make an outsourced host trustworthy with readable data. Local-first storage sidesteps outsourcing altogether, and zero-knowledge storage means the provider is holding something it cannot read in the first place. Neither of those makes HDS irrelevant in every case, and if you are unsure whether your setup qualifies as third-party hosting of health data, that is precisely the moment to ask a lawyer or your professional order. This article cannot make that call for you.

Retention: notes you no longer need are a liability

GDPR asks you to keep personal data no longer than necessary, and medical records carry their own retention rules depending on your profession and setting. The practical consequence for storage is simple: you need to be able to find, review, and delete old records, not just pile them up forever "to be safe." A giant undifferentiated folder of a decade of case notes is both a compliance problem and a breach-blast-radius problem. Storage that lets you organise, tag, search, and prune is not a nice-to-have here, it is part of doing this properly. The same discipline that keeps client documents organised and findable in one place is what lets you actually honour a retention or deletion obligation instead of guessing.

What this means in practice: a checklist

Whatever tool you land on, these are the concrete moves that carry most of the protection:

• Encrypt before it leaves your control. Prefer client-side or local encryption over "the cloud encrypts it for us." The question is always who holds the key. If you want the fundamentals, here is a practical guide to encrypting your notes and the threat models involved.
• Use a strong, unique passphrase and a real recovery plan. Client-side encryption means nobody can reset your password for you. That is the point, and it is also the risk. Write down and physically secure your recovery material.
• Back up, without breaking confidentiality. A single encrypted copy is one disaster from gone. Keep backups that are themselves encrypted, so a backup drive or sync target never becomes the weak link.
• Separate identifiers where you can. Pseudonymising notes (a code instead of a full name in the file body) reduces the damage if a single file is ever exposed.
• Keep a plan for lost devices. Full-disk encryption on the laptop, a screen lock, and knowing you can revoke or re-key matters more than any brand.
• Prune on a schedule. Review retention at least yearly and delete what you are no longer required to keep.
• Do not assume a tool makes you compliant. Compliance is your whole process: lawful basis, patient information, security, retention, and breach handling. Software is one ingredient.

If you also handle other regulated client files, the same reasoning that applies to a therapist's notes applies to any professional holding sensitive records; the analysis I wrote for accounting firms storing client documents under GDPR walks through Article 32's "appropriate to the risk" logic in more depth, and it transfers cleanly.

Where Filarr can help (and where it cannot)

Filarr is a local-first, encrypted workspace: notes, files, and a graph that links them, all living encrypted on your own machine. For a clinician's confidentiality problem, that maps onto the hard part well.

What it does: every file is encrypted with AES-256-GCM, with a separate key per file, so one file's key never unlocks the rest. Keys are derived from your passphrase using PBKDF2-SHA512 at 600,000 iterations (the OWASP 2024 recommendation), with Argon2id available as an option, and recovery goes through a 24-word BIP-39 phrase you control. By default nothing leaves your device: it works fully offline, so there is no third-party host reading your notes because there is no third-party host at all. If you do turn on the optional cloud sync, files are encrypted before they leave, and the server only ever stores opaque blobs it cannot decrypt, which is the zero-knowledge model described above. You can keep notes, patient-related PDFs, and case files in one place, organise them with tags and search, and prune what you no longer need. It is free forever for local use, with optional sync from 4 euros a month.

What it does not do, and this matters: Filarr is an encryption and storage tool, not a compliance certification and not legal advice. It is not, in itself, an HDS-certified host; if your situation legally requires certified third-party hosting, local-first storage changes the analysis but you must confirm your specific obligations with a qualified professional. It does not decide your lawful basis, write your patient-information notice, or handle a breach for you. It gives you strong confidentiality and data ownership. The rest of GDPR, and the whole of medical secrecy as a professional duty, remain yours to uphold. If you want to see exactly how the encryption is built rather than take the claim on faith, the design of the two-layer key hierarchy, KEK and FEK, is documented here.

FAQ

Can I keep patient notes in Notion or Google Docs? Technically yes, in practice it is a poor fit for identifiable health data. Both encrypt at rest but hold the keys, meaning the provider can read the content, and neither is generally contracted or certified for health records. For sensitive case notes, prefer client-side or local encryption where only you can read the file.

Is encryption enough to be GDPR compliant? No. Encryption is one of the security measures the GDPR explicitly recommends, and it is a strong one, but compliance also covers lawful basis, patient information, retention limits, and breach handling. A tool can give you excellent encryption and still leave the rest of your obligations untouched.

Do I legally need an HDS-certified host? It depends on whether a third party hosts identifiable health data on your behalf. Outsourced hosting of health data in France generally points to HDS. Data that stays on your own device, or that a provider only ever holds as ciphertext it cannot read, changes that analysis. When in doubt, ask your professional order or a lawyer, this article cannot decide it for you.

What happens to my notes if my laptop is stolen? With local, client-side encryption, a thief gets encrypted files that are useless without your passphrase, especially combined with full-disk encryption and a screen lock. Without encryption, a stolen device can mean a reportable breach of readable patient data. This is the single clearest argument for encrypting notes at the file level.

How do I back up encrypted patient notes safely? Keep backups that are themselves encrypted, so the backup never becomes the weak link, and store recovery material (like a recovery phrase) physically and separately. The goal is copies that survive a disaster without ever existing in readable form.

This article is general information for health professionals and is not legal advice. For your specific obligations under medical secrecy and the GDPR, consult your professional order or a qualified lawyer.