Diese Seite dient der technischen Einordnung von Praxissoftware: dieselben Fragen können Sie für jedes Praxisprogramm anhand der öffentlichen Dokumentation (Architektur-Hinweise, Datenschutzerklärung, ggf. Security-Whitepaper) beantworten. Wir nennen keine Wettbewerber – die Spalte „typisches serverzentriertes Web-PVS“ beschreibt ein Architekturmuster, das in der Branche verbreitet ist, ohne ein bestimmtes Produkt zu behaupten.
TLS schützt die Übertragung. Verschlüsselung ruhender Daten mit Schlüsseln des Betreibers ist für Gesundheitsdaten Stand der Technik – der Betreiber kann trotzdem entschlüsseln. kumppani verschlüsselt Inhaltsdaten im Browser; ohne den Masterkey des Kunden bleiben Chiffretexte. Entscheidend ist die Schlüsselhoheit, nicht das Wort „verschlüsselt“.
Aktualisiert: 8. September 2026| Kriterium | kumppani | Typisches serverzentriertes Web-PVS |
|---|---|---|
| Transportverschlüsselung (HTTPS / TLS) | Ja | Ja (Standard heute) |
| Verschlüsselung ruhender Daten (data at rest) | Ja – in der Speicherung liegen Chiffretexte, erzeugt im Browser. | Ja, typischerweise – Festplatten- oder Datenbankverschlüsselung mit Schlüsseln des Betreibers. Für Gesundheitsdaten Stand der Technik; TLS allein reicht dafür nicht. |
| Inhalts- bzw. Ende-zu-Ende-Verschlüsselung der synchronisierten Praxisinhalte vor Ablage, Schlüssel beim Kunden | Ja – Verschlüsselung im Browser (Web Crypto); ohne Masterkey des Kunden sind die Chiffretexte für den Betreiber nicht lesbar. | Typischerweise nein: At-Rest-Schlüssel liegen beim Betreiber. Die Anwendung entschlüsselt für Suche, Logik und Support. |
| Schlüsselhoheit für Inhaltsdaten / Klartext nur beim Kunden (Client) | Ja – Masterkey und Klartextverarbeitung im Browser; Betreiber sieht keine lesbaren Inhaltsdaten. | Typischerweise nein – Schlüsselmaterial und Klartext sind Teil des serverseitigen Betriebsmodells. |
| Zentraler Server kann Inhaltsdaten routinemäßig im Klartext verarbeiten (Suche, Logik, Auswertung) | Für die verschlüsselte Nutzlast: Nein – ohne Masterkey keine Auswertung durch den Betreiber. | Ja – das ist oft gerade der Zweck der Serverarchitektur. |
| Kann der Betreiber Inhaltsdaten lesen, wenn er es will – unabhängig von Support-Richtlinien? | Nein. Ohne den Masterkey des Kunden bleiben Chiffretexte; es gibt keinen serverseitigen Schalter, der uns die Akte zeigt. | Typischerweise ja. „Support sieht nur, was du freigibst“ ist eine Regel für Mitarbeiter. Wer Server oder Anwendungsschlüssel kontrolliert, kann denselben Klartext in der Regel auch ohne diese Freigabe lesen. |
Warum dieser Vergleich für Praxissoftware zählt
Viele Anbieter werben mit „verschlüsselt“. TLS und Verschlüsselung ruhender Daten mit Schlüsseln des Betreibers sind dafür die Pflichtübung: Für Gesundheitsdaten gilt At-Rest als Stand der Technik; TLS allein reicht nicht. Beides schützt nicht vor dem Betreiber. Wer die At-Rest-Schlüssel hält, kann die Akte lesen, wenn er es will. Die offene Frage ist Schlüsselhoheit: Liegt der Schlüssel nur beim Nutzer, oder beim Anbieter?
Die Tabelle trennt deshalb Transport, At-Rest und clientseitige Inhaltsverschlüsselung. So kannst du Anbieterdokumentation prüfen, ohne Markennamen zu vergleichen. kumppani folgt dem clientseitigen Modell: Web Crypto im Browser, Masterkey beim Nutzer, synchronisierte Chiffretexte. Typische serverzentrierte Systeme verschlüsseln ruhende Daten mit eigenen Schlüsseln und brauchen Klartext in der Anwendung für Suche, Logik und Auswertung – das ist ein anderes Bedrohungsmodell und sollte bewusst gewählt werden.
Achte beim Lesen von Sicherheitsseiten auf das Wort „technisch“. Es klingt nach Unmöglichkeit. Gemeint ist oft nur: Die Support-Oberfläche zeigt Inhalte erst nach einer Freigabe. Das setzt voraus, dass Klartext beim Betreiber liegt. Eine Richtlinie für Support ändert nichts daran, dass ein Administrator denselben Klartext lesen kann, wenn er es will. Die Prüffrage ist deshalb nicht „Was darf Support sehen?“, sondern „Kann der Betreiber die Akte lesen, wenn er es will?“
Für die Auswahl einer Praxissoftware reicht es nicht, ein Schloss-Symbol in der Broschüre zu sehen. Prüfe öffentlich, ob Inhaltsdaten clientseitig verschlüsselt werden, wer den Schlüssel hält und ob der Betreiber Klartext für Support, Suche oder Analytics benötigt. Der Vergleich hier ist bewusst architekturbezogen: Er ersetzt keine Rechtsberatung, hilft aber, Marketingbegriffe von technischen Zusagen zu trennen – und die eigene Risikoeinschätzung für Gesundheitsdaten zu schärfen.
Hinweis: Einzelprodukte können Mischformen haben (z. B. nur Teile clientseitig, zusätzliche HSM, TSE-only-Clouds). Entscheidend ist, was der jeweilige Anbieter öffentlich zur Schlüsselverwaltung und zum Zugriff auf Klartext schreibt. Unsere technische Darstellung von kumppani finden Sie unter Sicherheit & Verschlüsselung.
Kurz gefragt
Was ist der Unterschied zwischen TLS, At-Rest und Schlüsselhoheit?
TLS schützt die Übertragung. Verschlüsselung ruhender Daten mit Schlüsseln des Betreibers ist für Gesundheitsdaten Stand der Technik – der Betreiber kann trotzdem entschlüsseln. kumppani verschlüsselt Inhaltsdaten im Browser; ohne den Masterkey des Kunden bleiben Chiffretexte.
At-Rest mit Betreiberschlüssel schützt vor Diebstahl der Datenträger, nicht vor Admin, Support oder Anwendungslogik. Clientseitige Inhaltsverschlüsselung schützt die ruhenden Daten auch gegen den Betreiber.
Warum nennt ihr keine Konkurrenten?
Angaben zu fremden Produkten müssten wir jeweils belegen und aktuell halten; sonst entstehen rechtliche und fachliche Risiken. Die Tabelle soll Vergleichslogik liefern, die Sie mit jeder Dokumentation selbst abgleichen können.
Was bedeutet „technisch kein Zugriff“, wenn Support nach Freigabe Inhalte sehen kann?
Dann ist die Freigabe eine Richtlinie für Mitarbeiter, kein kryptografisches Unvermögen. Wer Server oder Anwendungsschlüssel kontrolliert, kann denselben Klartext in der Regel auch ohne diese Freigabe lesen. Bei kumppani gibt es diesen Pfad für Inhaltsdaten nicht: ohne den Masterkey des Kunden bleiben Chiffretexte.
Das Wort „technisch“ soll in solchen Sätzen Unmöglichkeit andeuten. Prüfe, ob der Anbieter damit meint: auch der Admin kann die Akte nicht entschlüsseln – oder nur: Support-Mitarbeiter sehen sie in der Oberfläche nicht, bis jemand freigibt.