Was ein DSGVO-konformes CMS für Arztpraxen wirklich braucht

Die meisten CMS-Plattformen sind darauf ausgelegt, Seiten zu veröffentlichen, nicht Patientendaten zu verwalten. WordPress, Webflow, selbst Headless-Tools wie Sanity sind für Inhalte optimiert: Artikel, Bilder, Marketingtexte. Die Website einer Poliklinik oder Privatpraxis braucht diese Ebene auch – aber sobald Online-Terminbuchung, Arztprofile mit echten Kalendern oder Patientendaten hinzukommen, ist das Projekt keine reine Content-Site mehr, sondern ein System, das besondere Kategorien personenbezogener Daten nach Art. 9 DSGVO verarbeitet.

Ein solches System wie ein Marketing-CMS mit angeflanschtem Buchungs-Plugin zu behandeln, rächt sich später meist genau dann, wenn ein Datenschutzbeauftragter, eine Versicherung oder eine Patientenbeschwerde einen Neubau erzwingt. Das muss tatsächlich anders sein.

Zwei Arten von Daten, zwei Zugriffsmodelle

Eine Praxis-Website enthält zwei sehr unterschiedliche Arten von Inhalten nebeneinander: öffentliche Marketinginhalte – Leistungen, Fachgebiete, Arztprofile – und operative Daten, die an echte Personen gebunden sind – Termine, Verweise auf Krankengeschichten, Einwilligungen. Diese sollten weder ein Schema noch eine Zugriffsschicht noch eine Backup-Richtlinie teilen.

Öffentliche Inhalte lassen sich aggressiv cachen und von fachfremdem Personal bearbeiten. Patientendaten brauchen zeilenbasierte Zugriffskontrolle, Audit-Logging und eine Aufbewahrungsrichtlinie, die unabhängig davon ist, wie lange ein Blogbeitrag online bleibt. In der Praxis bedeutet das ein Postgres-Backend – bei uns Supabase – mit Row-Level-Security pro Behandler, hinter einer eigenen Anwendungsschicht, getrennt von dem, was die öffentliche Seite ausliefert, selbst innerhalb derselben Next.js-App. Ein Arzt sollte nicht auf die Patientenliste eines anderen Arztes zugreifen können, nur weil die API-Route existiert. RLS erzwingt das auf Datenbankebene, nicht im Anwendungscode, den irgendwann jemand vergisst zu prüfen.

Buchung ist ein Nebenläufigkeitsproblem, kein Formularproblem

Die meisten Buchungs-Widgets behandeln Terminvergabe wie ein Formular: Zeit wählen, absenden, fertig. In der Produktion ist eine Doppelbuchung eine Race Condition – zwei Patienten bestätigen denselben Slot innerhalb derselben Sekunde, besonders bei stark nachgefragten Fachärzten.

Das korrekt zu handhaben bedeutet, eine Buchung als Transaktion mit einer Constraint auf Datenbankebene zu behandeln – ein Unique-Index auf Behandler und Zeitfenster, oder ein expliziter Row-Lock beim Schreiben – statt eines optimistischen UI-Updates, das annimmt, der Slot sei noch frei. Stornierung und Umbuchung brauchen dieselbe Garantie: Ein stornierter Slot muss atomar wieder buchbar werden, ohne ein Zeitfenster, in dem er weder reserviert noch verfügbar ist. Das ist im Datenbankdesign ein gelöstes Problem. Die meisten No-Code-Buchungstools überspringen es, weil es erst unter echtem Traffic auffällt, nicht in der Demo.

Einwilligung und Audit-Trails sind kein Extra

Die Verarbeitung besonderer Kategorien von Gesundheitsdaten erfordert eine ausdrückliche Rechtsgrundlage, und Praxen müssen nachweisen können – nicht nur behaupten –, wer wann auf welchen Patientendatensatz zugegriffen hat. Das bedeutet ein Audit-Log auf Datenebene: jeder Lese- und Schreibzugriff mit ausführendem Nutzer, Zeitstempel und Grund markiert, getrennt vom Datensatz selbst gespeichert, damit es im Nachhinein nicht manipulierbar ist.

Auch Einwilligung muss ein eigenständiger Datentyp sein, keine Checkbox, die eine E-Mail auslöst. Widerruft ein Patient die Einwilligung für Marketingkommunikation, behält aber seine Terminhistorie, muss das System das als getrennte, unabhängig widerrufbare Berechtigungen abbilden – nicht als ein Flag, das alles steuert.

Behandler und Leistungen strukturieren, nicht als Blogtext

Die öffentlichen Inhalte einer Praxis sind strukturierte Daten, kein Fließtext. Jeder Arzt braucht einen einheitlichen Inhaltstyp: Name, Fachgebiet, Qualifikationen, gesprochene Sprachen, zugeordnete Standorte und Leistungen. Jede Leistung braucht ihren eigenen Typ: Beschreibung, Dauer, welche Behandler sie anbieten, welche Versicherungs- oder Selbstzahlerbedingungen gelten. Das sauber in einem Headless-CMS zu modellieren – statt als Freitext-Seiten – erlaubt es einer Praxis, einen Arzt hinzuzufügen oder einen Standort zu eröffnen, ohne dass ein Entwickler Code anfassen muss, während die Daten des Buchungssystems konsistent mit dem bleiben, was öffentlich angezeigt wird.

Wo sich Individualentwicklung lohnt – und wo nicht

Generische Praxisverwaltungssoftware – Patientenakten, Abrechnung, E-Überweisungen – ist eine reife, regulierte Kategorie. In Kroatien übernimmt CEZIH bereits die nationale E-Health-Integration, das sollte eine Praxis nicht ersetzen wollen. Der Fall für ein individuell gebautes System ist enger gefasst: die öffentliche Website, das Buchungserlebnis und die Inhaltsebene, die Behandler, Leistungen und Standorte so verbindet, wie generische Vorlagen es nicht abbilden.

Der Fehler passiert in beide Richtungen – ein komplettes Patientenaktensystem von Grund auf zu bauen ist unnötig und ohne dedizierte Rechts- und Sicherheitsprüfung ein Compliance-Risiko, und ein öffentliches Buchungsformular an ein System anzuflanschen, das nie für personenbezogene Daten gedacht war, ist schlimmer. Der richtige Zuschnitt liegt dazwischen: eine sauber modellierte Content- und Buchungsschicht, gebaut auf einer Infrastruktur, die tatsächlich den Datenschutzanspruch erfüllt, den die Marketinginhalte allein nicht brauchen.

Wer einen Neubau für eine Praxis oder Poliklinik evaluiert, sollte einem Anbieter nicht nach Vorlagen oder Design fragen, sondern nach zeilenbasierter Zugriffskontrolle, Buchungs-Nebenläufigkeit und Audit-Logging. Für eine zweite Meinung zu einem bestehenden Setup oder ein konkretes Angebot für ein neues – gerne melden.