When a healthcare software promises “your data is encrypted,” what it really says is: we keep your data, and if someone accesses our servers, they’ll need a key to read it. That promise is useful. It’s also weaker than most people think.

For clinical data in mental health, the real standard — the one that follows from medical confidentiality and the spirit of European regulation — isn’t “encrypt well.” It’s don’t store at all.

What “zero-retention” actually means

Zero-retention means a piece of software keeps nothing of the clinical content it processes:

The dictation audio is not written to disk
The transcript is not persisted
The generated note is not stored on the servers
Nothing appears in application logs
Nothing remains in a cache

Concretely: the data transits through RAM for the duration of processing (a few seconds), the note is returned to the clinician’s browser, and all traces are immediately erased. If a server is seized the next day, there’s nothing to seize.

What remains on the platform side is what’s strictly needed to operate the service: the clinician’s email, their subscription, aggregated usage stats. No patient content.

Why it’s stronger than encryption

Encryption protects against an attacker who doesn’t have the key. But encrypted data still:

Gets copied to backups
Sits in application logs until their rotation
Is accessible to sysadmins with the key (or via a master key held on the same server)
Is vulnerable if the decryption process is compromised
Can be subpoenaed

Not storing removes all those risks with a single architectural decision. There’s nothing to subpoena, leak, decrypt, or back up. The risk isn’t reduced — it’s absent.

The GDPR (EU General Data Protection Regulation) and the Swiss FADP (new Federal Act on Data Protection, in force since September 2023) share three principles that converge on zero-retention.

Data minimization (GDPR Art. 5.1.c, FADP Art. 6.3). Only what’s strictly necessary should be processed. For a tool that turns clinical dictation into a note, processing is done the moment the note is returned. Any retention beyond that serves no legitimate purpose and isn’t compliant.

Storage limitation (GDPR Art. 5.1.e, FADP Art. 6.4). Data should not be kept beyond what’s necessary. For a transcription tool, “not beyond what’s necessary” may mean zero seconds after the note is produced.

Privacy by default (GDPR Art. 25). The controller must ensure by default that only necessary data is processed. Architecture is one such measure. Software designed not to persist data is compliant by construction — not by contractual promise.

Medical confidentiality points the same way

Medical confidentiality (Swiss Penal Code Art. 321, French Penal Code Art. 226-13) doesn’t stop at the office door. It extends to all auxiliaries of the clinician — and a note-taking software qualifies as such the moment it processes identifying or clinical content.

The more a subcontractor stores, the more it’s exposed to an incident that breaches confidentiality. The best strategy for a responsible subcontractor is to arrange its architecture to not be in a position to breach confidentiality, even by accident.

What zero-retention doesn’t solve

Intellectual honesty: zero-retention isn’t a panacea.

The AI provider (Whisper, Mistral, GPT, etc.) processes data for a few seconds. It may keep inference logs per its own policies. Its DPA should be read to verify it excludes training and prolonged retention.
The clinician’s browser may cache or historize the note. That’s the clinician’s responsibility.
Technical metadata (IP, timestamp, dictation length, specialty) continue to exist on the platform side for operational reasons. That’s not clinical content, but it exists.

Zero-retention doesn’t mean no data ever exists. It means no identifiable clinical content is kept.

What it changes in practice for the clinician

Three tangible consequences:

No lengthy DPA with the subcontractor. The DPA (Data Processing Agreement) is still required, but its content is simpler: no breach notification procedure, no data return procedure, no deletion procedure — because there’s nothing to breach, return, or delete.

The patient’s right of access becomes trivial. If the patient asks, under GDPR Art. 15, what data the subcontractor holds about them: none. The clinician can answer with documentation.

Security incidents are decoupled from clinical content. A compromise of Psydict’s server (as an example) would expose the list of subscribed clinicians and usage metadata. It would not expose a single word of a single note about a single patient.

Practical criteria for evaluating a tool

When a healthcare software claims “secure” or “GDPR compliant,” ask three precise questions:

Is clinical content (audio, transcript, note) persisted on your servers? If so, for how long and where?
Does it appear in application logs? If so, what’s the rotation policy?
Who, at your company, has technical access to the content in cleartext, and under what circumstances?

The answers “encrypted at rest” and “encrypted in transit” are insufficient. They describe how data is protected, not how long it exists.

Conclusion

Encrypting what you store is good practice. Not storing is better. For a tool that has no functional reason to keep the clinical notes it produces, zero-retention architecture isn’t a security luxury — it’s the logical consequence of data minimization and medical confidentiality.

The standard for clinical data in mental health should be this: if you don’t need it in five seconds, you shouldn’t have had it at all.