Making of praxifun: Vorgehen, Hosting, Monitoring, Sicherheit

Dieser Text richtet sich an eine Gruppe, die in der Diskussion um Praxissoftware selten vorkommt, aber am Ende alles ausbaden muss: an die Menschen, die eine Praxis technisch betreuen. Das sind oft keine Spezialisten für Gesundheits-IT, sondern der Bekannte mit Computerkenntnissen, der Systemhauspartner mit zwanzig anderen Kunden oder der Angehörige, der schon den Router konfiguriert hat. Die Arbeit ist trotzdem ernst: Sie verantworten faktisch die Infrastruktur, auf der Behandlungsdaten liegen — und Behandlungsdaten sind rechtlich und praktisch eine andere Klasse als Angebote und Rechnungen.

Deshalb beschreibe ich hier nicht, was praxifun kann, sondern wie es gebaut und betrieben wird. Nicht, weil unsere Entscheidungen die einzig richtigen wären, sondern weil sie nachvollziehbar sein sollen. Wer eine Praxis betreut, soll einschätzen können, was der Anbieter übernimmt, was liegen bleibt und wo die eigene Zuständigkeit beginnt. Die konkreten Produktnamen lasse ich bewusst weg — nicht aus Geheimniskrämerei, sondern weil die Kategorie die interessante Information ist und eine öffentliche Inventarliste der eigenen Infrastruktur niemandem nützt außer dem, der sie angreifen will. Auch das ist übrigens eine Entscheidung, die Sie für Ihre Praxis treffen sollten.

Vorgehen: Entscheidungen aufschreiben, bevor Code entsteht

praxifun entsteht seit Jahren nach einem Prinzip, das sich mit einem Satz zusammenfassen lässt: Jede nicht triviale Entscheidung wird vor der Umsetzung als kurzes Dokument festgehalten — Problem, betrachtete Alternativen, gewählte Lösung, Konsequenzen. In der Software-Welt heißen diese Dokumente Architecture Decision Records. Sie sind kurz, sie werden versioniert wie Quellcode, und sie werden nicht nachträglich schöngeschrieben.

Der Nutzen zeigt sich erst nach Monaten. Wenn ein halbes Jahr später die Frage auftaucht, warum Abrechnung und Dokumentation getrennte Datenmodelle haben, steht die Antwort mit Datum da, samt der damals verworfenen Alternative. Für eine Software, die medizinische Dokumentation führt, ist das kein Ordnungsfetisch, sondern die Vorstufe zur Nachweisbarkeit. Wer bei einer Prüfung erklären soll, wie sichergestellt ist, dass Einträge nachträglich nicht unbemerkt verändert werden, braucht mehr als die Aussage, dass man das schon richtig gemacht habe.

Zum Vorgehen gehört auch, Entscheidungen zurückzunehmen. praxifun hatte eine Sprachtranskription: Behandler diktieren, das System wandelt Audio in Text. Technisch lief das, selbst gehostet, ohne Fremdcloud, mit anschließender Löschung der Audiodateien. Trotzdem ist die Funktion entfallen. Wer Audio annimmt, verarbeitet eine zusätzliche Kategorie besonders sensibler Daten, braucht dafür eigene Einwilligungen, eigene Löschkonzepte, eigene Aufbewahrungsfristen und eine eigene Argumentationskette in der Datenschutz-Folgenabschätzung — für einen Komfortgewinn, den die Diktierfunktion eines Telefons oder Tablets ohnehin liefert. Das System verarbeitet heute kein Audio. Weniger Funktion, deutlich weniger Risiko.

Diesen Reflex empfehle ich jedem, der eine Praxis betreut: Bei jeder Komponente, die Daten annimmt, zuerst fragen, ob sie weg kann. Datenminimierung ist die einzige Sicherheitsmaßnahme, die nicht gepflegt werden muss.

Das dritte Element ist ein Register für Sicherheitsfunde. Jede erkannte Schwachstelle bekommt eine laufende Nummer, eine Bewertung und einen Status — auch die selbst gefundenen, auch die peinlichen, auch die, die niemand von außen je gesehen hätte. Inzwischen stehen über zwanzig Einträge darin. Eine Praxis braucht kein formales Register, aber sie braucht einen Ort, an dem bekannte offene Punkte stehen. Alles, was nur im Kopf des Betreuers existiert, verschwindet mit dem Betreuer.

Hosting: getrennte Systeme, benannte Verantwortung

praxifun läuft auf dedizierten Servern in Deutschland, bei einem Anbieter mit Auftragsverarbeitungsvertrag. Die Anwendung selbst liegt auf einem eigenen System, getrennt von allem, was nur Marketing ist — die Website, auf der Sie diesen Text lesen, hat mit dem System, das Patientendaten führt, technisch nichts zu tun. Das ist die erste und billigste Trennung, die man haben kann: Die Website ist das System mit den vielen Besuchern und den vielen Angriffsflächen, die Anwendung ist das System mit den wenigen, authentifizierten Zugriffen. Beide auf derselben Maschine zu betreiben, spart im Monat ein paar Euro und kostet im Ereignisfall alles.

Innerhalb der Anwendung läuft alles containerisiert hinter einem Reverse Proxy, der Zertifikate automatisch beschafft und erneuert. Datenbank, Anwendungsschicht und Hintergrundverarbeitung sind getrennte Einheiten mit getrennten Zugangsdaten. Die Praxen liegen in einer gemeinsamen Datenbank, aber mandantengetrennt: Jeder Datensatz trägt seine Praxiszuordnung, und die Zugriffsschicht setzt sie zentral durch, statt sie in jeder einzelnen Abfrage zu wiederholen. Mandantentrennung, die man in jeder Abfrage von Hand mitschreiben muss, ist keine Trennung, sondern eine Wettannahme auf Sorgfalt.

Auch der E-Mail-Versand läuft in eigener Verantwortung, mit korrekt gesetztem SPF, DKIM, DMARC und passendem Reverse-DNS-Eintrag. Das ist unspektakulär und nervig, entscheidet aber darüber, ob Terminerinnerungen im Postfach oder im Spamordner landen. Entwicklung und Auslieferung laufen ebenfalls auf eigener Infrastruktur in der EU, mit einem öffentlichen Dienst nur noch als nachgelagerte Kopie.

Für Sie als Betreuer ist an diesem Abschnitt weniger die Technik wichtig als die Zuständigkeitsgrenze. Beim Betrieb einer SaaS-Anwendung ist die Praxis Verantwortlicher im Sinne der Datenschutz-Grundverordnung, der Anbieter Auftragsverarbeiter. Der Anbieter schuldet den Auftragsverarbeitungsvertrag, die Beschreibung seiner technischen und organisatorischen Maßnahmen und die Auskunft, wo die Daten liegen und wer Zugriff hat. Alles, was am Empfang steht, gehört der Praxis: Endgeräte, Netz, Drucker, Bildschirme, Zugänge. Diese Grenze ist der häufigste blinde Fleck, den ich sehe. Server sind gehärtet, und danach klebt das Kennwort unter der Tastatur.

Monitoring: vier Fragen, die eine Antwort brauchen

Monitoring wird meist mit Dashboards verwechselt. Nützlich ist es, wenn es vier Fragen beantwortet, und zwar möglichst von außen, aus der Perspektive des Nutzers, nicht aus der Perspektive des Servers, der sich selbst für gesund erklärt.

Erstens: Ist die Anwendung erreichbar, und zwar tatsächlich anmeldefähig? Ein Server, der auf einen Ping antwortet, während die Datenbankverbindung steht, ist aus Sicht der Praxis ausgefallen. Prüfungen sollten einen echten Pfad durch die Anwendung nehmen. Zweitens: Laufen Zertifikate ab? Abgelaufene Zertifikate sind der banalste vermeidbare Ausfall, den es gibt, und automatische Erneuerung scheitert leise. Drittens: Gibt es ein aktuelles Backup, und wurde eine Rückspielung getestet? Ein Backup, das nie zurückgespielt wurde, ist eine Vermutung, kein Backup. Ich halte das für den am häufigsten ungetesteten Punkt in Praxen überhaupt — und die Prüfung kostet einen Nachmittag im Quartal. Viertens: Häufen sich Fehler oder ungewöhnliche Zugriffsmuster? Interessant ist nicht die einzelne Fehlermeldung, sondern die Veränderung der Rate.

Ein Detail, das in vielen Umgebungen falsch gelöst ist: Protokolldaten sind selbst datenschutzrelevant. Wer zur Fehlersuche Anfrageinhalte mitschreibt, legt Gesundheitsdaten in einem System ab, das häufig weniger geschützt ist als die Datenbank, oft länger aufbewahrt wird und manchmal bei einem Drittanbieter liegt. In praxifun enthalten Protokolle Kennungen und Zeitstempel, aber keine Inhalte. Prüfen Sie das bei jedem Werkzeug, das Sie in einer Praxis einsetzen, einschließlich Fehler-Tracking im Browser.

Und ein organisatorischer Punkt, der Technik schlägt: Monitoring ohne definierten Empfänger ist Dekoration. Es muss festgelegt sein, wer alarmiert wird, auf welchem Kanal und was passiert, wenn diese Person im Urlaub ist. Bei praxifun gibt es dafür einen vereinbarten Supportrahmen mit Erreichbarkeit an Werktagen — bewusst benannt, denn eine Zusage, die nur implizit besteht, ist im Ereignisfall keine.

Sicherheitsaspekte: die Angriffsfläche, die niemand erwartet

Die naheliegenden Maßnahmen sind vorhanden und schnell erzählt: Verschlüsselung im Transport, Verschlüsselung der personenbezogenen Felder in der Datenbank, sodass ein Datenbankabzug allein wenig hergibt, Rollen- und Rechteprüfung serverseitig, Geheimnisse ausschließlich über Umgebungskonfiguration und nicht im Quellcode, regelmäßige Aktualisierung der Abhängigkeiten. Wer das nicht hat, ist nicht im Gespräch.

Diese Grundlage haben wir nicht nur selbst behauptet, sondern extern prüfen lassen. Im August lief praxifun in einer Sicherheitskampagne mit, die der Produkt- und Technikchef eines niederländischen Softwareunternehmens veranlasst hatte: KI-gesteuerte Agenten versuchten 24 Stunden lang, von außen an Daten zu kommen. Das ist ein Unterschied, der eine Erläuterung verdient: Die Versuche wurden nicht von einem Prüfer nach Checkliste durchgespielt, sondern von Agenten, die die Anwendung selbständig erkunden, Antworten auswerten und aus jeder Reaktion den nächsten Versuch ableiten — in einer Geschwindigkeit und Breite, die ein Mensch in derselben Zeit nicht erreicht, und ohne Feierabend. Gelungen ist es nicht: kein Zugriff auf Daten, keine Übernahme eines Kontos, kein Ausbruch aus der Mandantentrennung. Das war ein guter Tag, aber es ist nicht der eigentliche Gewinn. Der eigentliche Gewinn liegt in dem, was ein solcher Test nebenbei sichtbar macht: Dienste, die von außen antworteten, obwohl sie es nicht müssen, Fehlermeldungen, die mehr über die eingesetzte Technik verrieten als nötig, Endpunkte, die zwar korrekt abgesichert waren, aber überhaupt nicht öffentlich erreichbar sein mussten. Nach dem Test haben wir die Angriffsfläche deutlich weiter reduziert — nicht, weil etwas kaputt war, sondern weil sich vieles einfach abschalten ließ.

An dem Verfahren hängt eine Einsicht, die für Ihre Arbeit wichtiger ist als unser Ergebnis. Ein solcher Test kostet heute einen Bruchteil dessen, was ein manuelles Audit vergleichbarer Breite kostet — und genau das gilt auch für die Gegenseite. Die Annahme, eine kleine Praxis sei zu unbedeutend, um gezielt angegriffen zu werden, war schon immer eine Hoffnung und ist jetzt endgültig hinfällig: Wer automatisiert und agentengesteuert sucht, braucht keinen Grund, sich für ein einzelnes Ziel zu interessieren. Die gute Nachricht derselben Entwicklung ist, dass diese Werkzeuge auch der Verteidigung offenstehen. Eine Prüfung der eigenen Praxis-Infrastruktur von außen ist heute keine Frage des Budgets mehr, sondern der Entscheidung.

Daraus folgt eine Frage, die Sie jedem Anbieter stellen sollten, und zwar in zwei Teilen: Hat ein externer Test stattgefunden, und was wurde danach geändert? Der erste Teil wird gern beantwortet, der zweite ist der aussagekräftige. Ein Prüfbericht ohne nachfolgende Änderungen bedeutet entweder, dass der Test zu oberflächlich war, oder dass die Ergebnisse liegen geblieben sind. Umgekehrt gilt dasselbe für Ihre eigene Arbeit: Ein Test der Praxis-Infrastruktur ist erst dann etwas wert, wenn die Liste der Nebenbefunde abgearbeitet ist — und die besteht erfahrungsgemäß weniger aus Lücken als aus überflüssig Erreichbarem.

Interessanter sind die Funde, die wir selbst nicht erwartet hatten, weil sie ein Muster zeigen. Drei Beispiele in abstrakter Form. Zum einen die Vertrauensgrenze für Client-Adressen: Wenn eine Anwendung hinter einem Proxy steht, glaubt sie das, was der Proxy ihr über die Herkunft einer Anfrage erzählt. Ist diese Grenze nicht exakt definiert, kann ein Angreifer seine eigene Adresse behaupten — und damit jede Sperre umgehen, die auf Adressen aufbaut. Zum anderen Begrenzungen auf nur einem Merkmal: Eine Drosselung, die allein pro Adresse zählt, hilft nicht gegen verteilte Versuche gegen ein einzelnes Konto, und eine Drosselung allein pro Konto lässt Massenversuche durch. Man braucht beides. Und schließlich öffentliche Formulare: Ein Patientenportal, das Termine anbietet, erlaubt Unbekannten, Zustände im System zu verändern. Ohne Gegenmaßnahmen lassen sich sämtliche freien Termine blockieren oder fremde Adressen mit Bestätigungsmails überschütten. Kein Datenabfluss, aber ein arbeitsunfähiger Betrieb.

Das Muster: Die gefährlichen Lücken liegen selten in der Verschlüsselung. Sie liegen an den Rändern — dort, wo eine Komponente einer anderen etwas glaubt, und dort, wo Unbekannte ohne Anmeldung etwas auslösen dürfen. Übertragen auf eine Praxis heißt das: Prüfen Sie, was ohne Anmeldung erreichbar ist. Das Fernwartungswerkzeug mit Standardkennwort, der Netzwerkdrucker mit offener Weboberfläche, die Portfreigabe im Router, die seit einem Projekt von 2019 existiert, das Gäste-WLAN, das im selben Netz hängt wie der Karteirechner.

Was Sie außerdem im Blick behalten sollten

Drei Punkte fallen mir bei fast jeder Praxis auf, unabhängig von der eingesetzten Software.

Erstens die Endgeräte. Die Anwendung kann beliebig gut abgesichert sein — wenn der Rechner am Empfang ungesperrt bleibt, während niemand davor sitzt, oder wenn Behandler ihre Zugangsdaten teilen, weil das Anlegen zweiter Benutzer als Umstand empfunden wird, ist die serverseitige Rechteprüfung wertlos. Eigene Benutzerkonten pro Person, automatische Bildschirmsperre und ein Bildschirm, auf den kein Wartender schauen kann, bringen mehr als jede zusätzliche Verschlüsselungsschicht.

Zweitens Aufbewahrung und Löschung. Behandlungsdokumentation unterliegt eigenen Fristen, in der Regel zehn Jahre, und muss nachträgliche Änderungen erkennbar machen. Das kollidiert mit dem Reflex, auf Wunsch alles zu löschen. Beides zusammen bedeutet: Änderungen werden nachvollziehbar protokolliert, Löschung erfolgt fristgerecht und dokumentiert, nicht auf Zuruf. „Revisionssicher" ist dabei kein geschützter Begriff — er steht in vielen Prospekten und sagt für sich genommen nichts darüber, ob eine Änderung im Datenbestand tatsächlich rekonstruierbar ist. Fragen Sie deshalb bei jedem Anbieter konkret nach: Was passiert, wenn ein Dokumentationseintrag nachträglich korrigiert wird — bleibt die vorherige Fassung erhalten, werden Zeitpunkt und Person festgehalten, und lässt sich beides auslesen, ohne dass der Hersteller helfen muss? Die Qualität der Antwort ist aussagekräftiger als jede Zertifikatsgrafik.

Drittens Ausstieg und Notfall. Zwei Fragen, die vor dem Vertrag gestellt werden sollten und meist erst danach gestellt werden: Wie kommen die Daten in einem offenen Format wieder heraus, wenn die Praxis wechseln will? Und wie wird gearbeitet, wenn das System einen Tag nicht erreichbar ist — wer greift zum Telefon, wo werden Behandlungen notiert, wer trägt sie nach? Eine Seite Papier, die das beantwortet, ist mehr Notfallvorsorge als die meisten Praxen haben. Dazu gehört auch Schatten-IT: Sobald Befunde über private Mailkonten oder Messenger laufen, weil der offizielle Weg als zu langsam empfunden wird, ist jede technische Maßnahme umgangen. Das ist selten Böswilligkeit, fast immer ein Usability-Problem — und damit ein Hinweis an die Software, nicht an die Mitarbeiter.

Kurz gesagt

praxifun ist kein Produkt aus einer großen Organisation, sondern aus wenigen Händen, mit langer Vorgeschichte und schriftlich festgehaltenen Entscheidungen. Genau deshalb sind Vorgehen, Trennung der Systeme, geprüftes Wiederherstellen und benannte Verantwortung wichtiger als jede Funktionsliste. Wenn Sie eine Praxis betreuen und aus diesem Text nur drei Dinge mitnehmen, dann diese: Spielen Sie ein Backup zurück, bevor Sie es brauchen. Sehen Sie nach, was ohne Anmeldung erreichbar ist. Und schreiben Sie auf, wer im Ereignisfall was tut.

Fragen zu einzelnen Punkten beantworte ich gern — auch kritische, gerade von Kollegen, die es besser wissen. Genau daraus entstehen die nächsten Einträge im Register.

Wie das im Betrieb aussieht, steht ausführlicher unter Hinter den Kulissen; was praxifun fachlich kann, unter Funktionen. Sprechen Sie mich an — 30 Minuten online, unverbindlich und kostenlos.