Deutschland · DSGVO · § 203 StGB · § 630f BGB · NIS2 · SGB V
German practices are held to the European rules everyone knows, and then to a second layer that is specifically German. One of those German rules is not a data protection rule at all — it is criminal law, and it puts the therapist personally at risk over the choice of software supplier.
This page explains the German layer in ordinary words, says what we can put in writing, and is equally clear about the part of the German market we cannot serve. That last section is short and it is not hidden.
Almost every article written about health data in Germany is really about the DSGVO — the German name for the GDPR. That part is European and it applies identically in Vienna, Amsterdam and Berlin. It is covered on the GDPR page, and everything there applies here unchanged.
What makes Germany different is the second layer sitting on top: national law that goes further than the GDPR does, in ways that change what a practice may buy. There are four pieces to it, and the first is the one nobody expects.
Confidentiality in German healthcare is not only a professional duty. Breaking it is a criminal offence. And since a 2017 reform, the practitioner also commits an offence if they let an IT supplier near patient data without binding that supplier to secrecy in writing first.
Why it matters to a software decision: this is the rule that decides whether a practice may lawfully buy from us at all. Section 02.
Patient records must be kept for ten years after the treatment ends — not ten years after the file was made. The professional code for psychotherapists says the same.
Why it matters: a retention rule counted from the wrong date is wrong every time. Our retention works from the end of treatment, which is the right anchor. Section 05.
In force in Germany since December 2025. Health is in scope, and the threshold is roughly 50 staff or €10m turnover. It brings a risk-management programme, incident reporting within 24 and 72 hours, supply-chain duties — and personal liability for management.
Why it matters: a single practice is out of scope; a growing group is not. Section 06.
To bill the statutory insurers through a Kassenärztliche Vereinigung, a practice must run a system that has passed gematik's KOB conformity assessment and is connected to the Telematikinfrastruktur.
Why it matters: we do not have that certification, so statutory billing is closed to us. This is a boundary, not a backlog, and section 07 says so plainly.
If you run a private practice — Privatpraxis, Selbstzahler, private insurance or Beihilfe — everything on this page is workable and § 203 is the conversation to have. If you hold a Kassensitz and bill a KV, you need a KOB-certified system and we are not one; the honest answer is that we are not your practice-management system, and section 07 explains what we could still be.
This is the most important section on the page, and it is worth reading even if you delegate every other compliance question. It is short, it is unusual, and it decides whether a purchase is lawful.
A German psychotherapist who lets the wrong person see a patient's file does not merely breach a professional rule. They commit a criminal offence.
That has always been true. What changed in 2017 is how it applies to the ordinary reality that somebody has to maintain the software.
The law created a category called sonstige mitwirkende Personen — other participating persons. An IT supplier may be let inside the circle of secrecy, as far as is necessary for the work, and no further. The statute's word is erforderlich.
So a supplier seeing patient data during a support session is not automatically a breach. It is lawful — if the condition below is met.
The practitioner must bind the supplier to secrecy in writing, and must expressly instruct them about the criminal consequences of a breach, before access is given.
If they do not, the practitioner has committed the offence — up to one year's imprisonment or a fine. Not the supplier. The practitioner.
This is the part that surprises people. The wrong is the failure to bind, not the leak. A practice that gave a supplier access without the undertaking has already committed the offence, on a day when nothing at all went wrong.
Which is why a German practice's lawyer will ask for this document before signature, and will stop the purchase if it does not exist.
Dr. Weber, four-therapist practice, München
Same practice, same Tuesday
The Auftragsverarbeitungsvertrag (AVV) is the GDPR processing contract. Every supplier has one, and it protects against fines from the data protection authority.
The § 203 Verpflichtungserklärung is a separate document under criminal law. It protects the practitioner against prosecution. An AVV does not satisfy § 203, and a supplier who offers only an AVV has not answered the question. Both are needed.
A § 203 Verpflichtungserklärung is short — two to three pages. Below is what one contains, and beside each clause, what we can honestly promise against it. Some of these are stronger for us than for a cloud supplier, and one of them is a straight admission.
Read the status column carefully. The architecture that makes these promises credible exists today. The document itself does not exist yet, and this page will not pretend otherwise.
| Clause in the undertaking | Status | What it says, and what we can promise |
|---|---|---|
| 1 · Who and what | — | Names both parties and states which service contract it supplements. It is an add-on to the main agreement, never a standalone document, and it sits alongside the AVV rather than inside it. |
| 2 · Acknowledgement of status | — | We confirm in writing that we act as a sonstige mitwirkende Person under § 203 Abs. 3 — that is, we accept being inside the circle of secrecy rather than an outsider with a contract. Accepting that status is what makes the practice's involvement of us lawful. |
| 3 · The confidentiality promise | — | We keep secret everything we learn: names, appointments, session content — and the fact that a named person is a patient at all. In psychotherapy that last one is often the whole secret, and a clause that omits it has missed the point. |
| 4 · Access only as far as necessary | ✓ | The statute's test is erforderlich — necessary. This is where our architecture earns its place. We hold no copy of your data: the system runs on your server. We have no standing access. Support access is requested, granted for a job, and withdrawn. That is not a policy we are asking you to trust; it is what self-hosting means. |
| 5 · The Belehrung — instruction on criminal consequences | — | The document must expressly state that a breach is punishable under § 203 Abs. 4 Satz 1 StGB by up to one year's imprisonment or a fine. A confidentiality clause without this warning does not satisfy the statute — it is the single most common defect in supplier paperwork, because ordinary NDAs never contain it. |
| 6 · Our own staff, individually bound | — | It is not enough for a company to promise. Each engineer who could reach your system must be personally committed in writing. The undertaking obliges us to do that and to keep the records. |
| 7 · Sub-contractors | ⚙ | Anyone we bring in — hosting, backup, an outside developer — must be agreed with you in advance and bound identically before touching anything. The chain must be unbroken and you must know who is in it. Because you host the system yourself, this chain is normally very short or empty, and you control the hosting end of it. |
| 8 · The duty survives the contract | — | Not five years. Indefinitely. An engineer who leaves us is still bound in 2040, and so are we after you stop being a customer. |
| 9 · Return or destruction at the end | ✓ | Confirmed in writing when the relationship ends. Lighter for us than for most: there is normally nothing on our side to return, because the data never left your server. Where a diagnostic export was made for a support case, its destruction is confirmed. |
| 10 · Immediate termination | — | You may end the contract on the spot if compliance stops being assured. This is your protection, not ours, and it belongs in the document. |
| 11 · Form | — | Textform is sufficient — a signed PDF by email is enough for medical practitioners. Only notaries require full written form. So this is not an obstacle to a remote purchase. |
| 12 · Evidence that the clauses were honoured | ✓ | Not a standard clause, and worth adding. Every opening of a clinical record is written to a log before the content is shown — including ours during support. The log is append-only and chained, so entries cannot be edited or removed, by your administrator or by us. If anybody ever asks who saw a file and when, the undertaking is backed by a record instead of an assurance. |
The rows marked ✓ describe how the platform works now and can be shown to you in a demonstration. The document is not drafted. It needs writing and it needs review by a German Fachanwalt für Medizinrecht before it goes to any practice, because the liability it addresses is criminal and a template found online is not good enough.
If you are evaluating us and this document is on your checklist, say so early. It is a short piece of work and it is not a technical dependency — but it should not be improvised in the week of signature.
A cloud practice-management service holds your patient records on its own infrastructure, and its staff can reach them by design. Its § 203 exposure is permanent and broad, and no wording changes that.
Our answer to "how far does the supplier need to see?" is normally, not at all — and when the answer is "for the next hour", the access is granted by you, recorded, and withdrawn. The statutory test is necessity, and that is an architecture question before it is a drafting question.
§ 203 turns on one question: how much did the supplier need to see, and can you show it. So here is the sequence, step by step, for the ordinary case where something breaks and you ask us to look.
The system runs on your server, in your building or your data centre. There is no permanent connection from us to it and no copy of your data on our side. This is the state the system is in almost all of the time.
Usually with a description and a screenshot, which is often enough on its own.
Many issues are settled from logs and error text with no access to patient data. That is the cheapest answer under § 203 as well as the fastest.
Not a standing account. An account for this piece of work, which you can end at any moment.
There is no supplier back door and no maintenance override. A support account is subject to the same checks a clinician's account is.
no general override existsEncrypted records open only for someone with a recorded care relationship with that client. A support engineer has none, so the ordinary answer is refusal — and the ordinary support case never needs them.
Before the content appears. Append-only and chained, so an entry cannot be quietly removed afterwards — not by us, and not by your own administrator.
And the record of what was reachable, and for how long, stays.
Who connected, when, what was opened. This is the evidence that the necessity test was met — which is exactly what a lawyer, an auditor or a complaining patient will ask for.
§ 630f Abs. 3 BGB requires patient records to be kept for ten years after the treatment ends. The psychotherapists' professional code says the same. It sounds simple and it is where a surprising number of systems are quietly wrong.
| What the rule asks | Status | How it works here |
|---|---|---|
| Ten years from the end of treatment§ 630f Abs. 3 BGB | ✓ | The clock runs from a stored date — the end of the treatment relationship — rather than from when a document happened to be created. A note written in the first session and one written in the last are kept until the same day, which is what the rule means and not what a file-age rule would produce. |
| The German period, ready to use | ⚙ | The mechanism is built and the ten-year German period is entered as a setting. We ship the NHS schedule ready-made for British customers and do not yet ship a German equivalent, so this is one line of configuration at installation rather than something already filled in. We would rather say that than let you discover it. |
| Disposal that can be proved | ✓ | When the period expires the encryption key is destroyed rather than the row. The content becomes permanently unreadable while an empty shell and the audit trail remain — so you can show that a record existed and was disposed of on schedule, which a deleted row cannot. |
| Nothing destroyed while a hold is in place | ✓ | A legal hold suspends disposal. Litigation, a complaint or an insurance dispute stops the clock without anyone having to remember to intervene. |
| Longer periods where they apply | ⚙ | Some material is kept for thirty years under other provisions — not usually relevant to psychotherapy, but if your practice holds any, the period is set per document type rather than for the whole file. |
NIS2 is the European cybersecurity directive. Germany brought it into force in December 2025, and healthcare is one of the sectors it covers. The threshold is roughly 50 staff or €10 million turnover.
A single practice is out of scope and can stop reading here. A group of six locations with sixty staff is in scope — and the duties are real: a documented risk-management programme, an early incident report within 24 hours and a fuller one within 72, checks on your own suppliers, and personal liability for management.
Most practice-management systems have nothing to say about this, because it is not a records feature. We do, because the same machinery was already built for American healthcare rules and the two lists overlap almost completely.
| What NIS2 asks of you | Status | What the platform already holds |
|---|---|---|
| A risk-management programme, written down | ✓ | A risk register: each risk with its asset, threat, weakness, likelihood, impact, the control already in place, the risk left over, an owner and a review date. An assessment cannot be approved while a risk is unrated, and one with no risks in it cannot be approved at all — an empty register is a finding, not a clean bill of health. |
| Incident handling | ✓ | An incident record with the moment you became aware, what was involved, who was affected, and the decisions taken. The 24-hour and 72-hour clocks are the same shape as the GDPR 72-hour clock already built, counted from awareness rather than from the event. |
| Business continuity and backup | ✓ | A contingency plan, its tests with their results, and an analysis of which systems and data matter most. The test records are the part auditors ask for, because a backup nobody has restored is a hope rather than a control. |
| Supply-chain security | ✓ | A supplier register with agreements and their dates — and a disclosure to a supplier is refused if the agreement has lapsed. It also helps that your most sensitive supplier, the software vendor, holds none of your data. |
| Access control, joiners and leavers | ✓ | An authorisation register saying who was granted what and when it was last reviewed, and a termination record — the evidence that access ended on the day somebody left rather than three months later. |
| Training and awareness | ✓ | Training records per person, alongside the qualifications and expiry dates the practice already tracks. |
| Cryptography and access to data | ✓ | Clinical documents encrypted individually under keys held outside the database, with every opening recorded. See the secure documents page for how that works and where its limits are. |
| Effectiveness review | ✓ | A periodic evaluation record with a date on it, so "when did you last check whether any of this still works?" has an answer. |
| Registration with the BSI | — | Yours to do, not ours. The German registration window opened with the law and closed in March 2026; if you are in scope and have not registered, that is a conversation for your counsel rather than for a software supplier. |
Every row above is a place to keep a record. A risk register with nothing in it evidences nothing, and an auditor looks at the records rather than at whether the software has somewhere to hold them. What the platform removes is the excuse that there was nowhere to write it down — and the cost of buying a separate governance tool to do it.
This section exists because you will find it out anyway, and finding it out late is worse for both of us. It is short.
Private practice is genuinely open. Privatpraxis, Selbstzahler, private insurance and Beihilfe need none of the above, and German statutory waiting lists have made private-pay psychotherapy a large and growing part of the market.
And a practice with a Kassensitz is not necessarily out of the conversation. The statutory rail is one part of running a practice. Multi-site operations, staff scheduling, practitioner payouts, contracts, secure clinical documents and the governance programme in section 06 are the parts the certified German systems handle least well, because they were built for one-to-five person practices. Some groups run us alongside a certified PVS rather than instead of it. That is a real deployment shape, and it is worth discussing openly rather than pretending the certification does not matter.
Not a feature list — the German systems have plenty of features. These are the places where the way this platform is built produces an answer the incumbents structurally cannot give.
Self-hosted on your own server. We hold no copy. That is the shortest possible answer to the § 203 necessity test, and no cloud service can give it.
A deletion request destroys the encryption key, not just the row. The content becomes permanently unreadable while the proof of disposal survives. Deleting a database row is reversible from a backup; this is not.
Every opening of a clinical record, written before the content appears, in a chain where a removed entry is detectable. Not even your own administrator can quietly change it.
Not the job title. A therapist reaches their own clients, not the practice's, and access ends when the relationship does. This is minimum necessity built into the storage rather than written in a policy.
There is no maintenance override and no support super-user. An administrator account opens no clinical content by itself either.
Multi-site scheduling, practitioner payouts, contracts and group reporting. The German incumbents were built for one-to-five person practices and show it as soon as a group grows.
Risk register, incident records, continuity tests, training, access reviews. Not a separate tool and not a consultant's spreadsheet.
Built on Odoo Community. Your own security people, or testers you hire, can read every line rather than take a supplier's word for it.
Consent forms and treatment contracts are signed on your own system with their own audit trail. Nothing is sent to an outside signing service to be countersigned.
German law places its duties on the practitioner and the practice, not on the software. A supplier can hold the evidence and make the workflow real. It cannot be the Berufsgeheimnisträger.
Nothing here is legal advice, and no software is "DSGVO-zertifiziert" or "§ 203-konform" — those certificates do not exist for products. Everything below is yours, and every statement on this page should be confirmed with a German Fachanwalt für Medizinrecht before it reaches a contract. That applies with particular force to § 203, because the liability there is criminal.
The European rules apply here as they do everywhere and are covered on the GDPR page. On top of them Germany adds criminal professional secrecy, which makes the choice of supplier a legal question for the practitioner rather than a procurement one — and self-hosting is the strongest available answer to it. Records are kept ten years from the end of treatment, which our retention anchors handle correctly. Larger groups now fall under NIS2, and the governance programme the platform already carries covers most of what that asks. What we do not have is the statutory rail: no KOB certification, no Telematikinfrastruktur, no KV billing, no certified video service. Private practice is open to us; a Kassensitz needs a certified system, whether alongside us or instead of us.
