Praxissoftware aus der Cloud: das C5-Testat aus Sicht des Herstellers

Diese Seite richtet sich an Hersteller von Praxisverwaltungs- und anderer Praxissoftware, die ihre Software als Cloud-Dienst anbieten. Für Praxen, die einen Anbieter auswählen, und für die Rechtsgrundlage gibt es die Seite § 393 SGB V: Sie erklärt, wen die Norm betrifft, welche Fristen gelten und warum das Testat des Hosters allein nach unserer Einschätzung nicht reicht. Diese Seite wiederholt das nicht und ist keine Rechtsberatung.

Das Beispiel: eine Praxisverwaltung aus der Cloud

Fiktives Beispiel, kein Kunde. Ein Hersteller bietet ein Praxisverwaltungssystem für Arztpraxen als Cloud-Dienst an. Die Architektur:

• Anwendung im Browser, betrieben auf einer Cloud-Plattform in einer Region in Deutschland, Datensicherung in einer zweiten Region in Deutschland; je Praxis ein eigener Mandant.
• Lokale Komponente auf einem PC in der Praxis, die Kartenlesegerät, Drucker und einzelne Geräte anbindet und mit der Anwendung verschlüsselt kommuniziert. Der Hersteller entwickelt sie und verteilt Updates; Hardware und Betriebssystem gehören der Praxis.
• Support durch ein eigenes Team, das sich auf Wunsch der Praxis in deren Mandanten schaltet, um Fehler zu finden.
• Datenübernahme aus dem Altsystem einer Praxis beim Umstieg und Export aller Daten, wenn eine Praxis kündigt.
• Eine ältere Version derselben Software wird weiterhin lokal installiert verkauft.

Wer was verantwortet: Hersteller, Plattform, Praxis

Die rechte Spalte gehört in die Systembeschreibung als korrespondierende Kundenkontrollen (CUEC), die der Hersteller bei der Ausgestaltung seiner Kontrollen voraussetzt (Abschnitt 3.4.5.1 Nr. 7). Jede dieser Pflichten braucht eine Formulierung, die die Praxis umsetzen und belegen kann, und einen Bezug zu den korrespondierenden Kriterien für Kunden aus dem Katalog.

Entscheidung 1: Gehört die lokale Komponente in den Scope?

Nach unserer Einordnung zum Teil. Ihre Entwicklung, die Signatur und die Verteilung der Updates liegen beim Hersteller und betreffen den Dienst direkt; sie gehören in den Prüfungsgegenstand, mit denselben Kontrollen für Änderungen, Tests und Freigaben wie die Anwendung. Der Betrieb des Praxis-PCs liegt bei der Praxis. Kriterien, die sich darauf beziehen würden, lassen sich nur ausschließen, wenn die Begründung sich auf Art und Ausgestaltung des Dienstes oder auf die Grundsätze, Verfahren und Maßnahmen des Herstellers stützt (Abschnitt 3.4.3); dass der Hersteller keine Kontrolle hat, weil er sie nicht eingerichtet hat, genügt nicht. Die Pflichten der Praxis stehen dann als vorausgesetzte Kundenkontrollen in der Systembeschreibung, die Hinweise für den sicheren Betrieb in den Leitlinien für Kunden (PSS-01).

Entscheidung 2: Wie der Support auf Praxisdaten zugreift

Zugriffe des Herstellers auf Daten der Kunden regelt IAM-07 „Zugriff auf Cloud-Kundendaten“. Für den Support sind drei Unterkriterien wichtig:

• IAM-07.06B: Der Hersteller legt vertraglich und vor dem Anbieten des Dienstes alle Fälle offen, in denen er auf Kundendaten in unverschlüsselter Form zugreifen kann.
• IAM-07.03B bis .05B: Greift Personal ohne vorherige Zustimmung der Praxis auf ihre Daten zu, wird die Praxis je Ereignis informiert, soweit unverschlüsselt zugegriffen wurde oder der Vertrag die Information nicht ausdrücklich ausschließt. Sofern vertraglich nichts anderes vereinbart ist, nennt die Information Anlass, Zeitpunkt, Dauer, Ort, Art und Umfang des Zugriffs und die Aufbewahrungsdauer dabei erzeugter Daten wie Protokolle oder Kopien; sie kommt spätestens 72 Stunden ab Einleitung des Zugriffs.
• IAM-07.03AS (Zusatzkriterium): Zugriffe brauchen die vorherige Zustimmung von autorisiertem Personal des Kunden, soweit die Daten unverschlüsselt zugänglich sind oder der Vertrag die Zustimmung nicht ausdrücklich ausschließt.

Unsere Einordnung für Praxissoftware: Der Ablauf, in dem die Praxis den Support anfordert und freischaltet, ist im Beispiel ohnehin vorhanden. Wer ihn technisch erzwingt und protokolliert, kann das Zusatzkriterium IAM-07.03AS mit wenig Mehraufwand aufnehmen, und Praxen sehen im Bericht, dass niemand ohne Freigabe in ihre Daten schaut. Für Notfälle braucht es eine vertragliche Regel. Wie privilegierte Zugriffe insgesamt prüffähig werden, siehe Themengebiet IAM. Ob Wartungs- und Supportzugriffe nach § 393 SGB V eine Verarbeitung sind und was der GeDIG-Entwurf daran ändern würde, behandelt die Seite § 393 SGB V und Wartungszugriff.

Entscheidung 3: Datenübernahme und Rückgabe beim Wechsel

PI-02 verlangt vertragliche Regeln für die Bereitstellung der Kundendaten nach Vertragsende: Art, Umfang und Format der Daten, Methoden der Übergabe, Fristen, den Zeitpunkt, ab dem der Hersteller die Daten unzugänglich macht und löscht, die Mitwirkungspflichten des Kunden und dass die Daten Eigentum des Kunden bleiben (PI-02.01B). Für Praxissoftware heißt das nach unserer Einordnung: Exportformat und Frist gehören in den Vertrag, bevor die erste Praxis kündigt, und der Export braucht einen Test, nicht nur eine Beschreibung. Die Aufbewahrungspflichten der Praxis nach Berufs- und Datenschutzrecht sind ihre eigenen; der Vertrag sollte so gestaltet sein, dass sie diese nach dem Export selbst erfüllen kann. Ob und wie lange der Hersteller Daten für die Praxis aufbewahrt, ist eine Vertragsfrage und rechtlich gesondert zu prüfen.

Die Übernahme aus einem Altsystem ist das Gegenstück: Sie verarbeitet Kundendaten außerhalb des Regelbetriebs, oft mit Werkzeugen und Zwischenablagen, die nur dafür entstehen. Unsere Empfehlung: Den Import als eigenen, beschriebenen Prozess in den Scope nehmen, mit Löschung der Zwischenstände.

Entscheidung 4: Praxen in Freigaben einbinden

DEV-10.02B verlangt, Kunden gemäß den vertraglichen Vereinbarungen in die Freigabe von Änderungen einzubeziehen. Sagt der Vertrag den Praxen zu, dass Änderungen vorher angekündigt werden oder nur in Wartungsfenstern kommen, wird diese Zusage zur prüfbaren Kontrolle. Halten Sie im Vertrag nur fest, was Sie für jede Änderung im Prüfungszeitraum belegen können.

Cloud-Version und lokale Version im selben Haus

Ein C5-Testat gilt nach der FAQ des BSI für die geprüften Cloud-Dienste in festgelegten Regionen, nie für den Hersteller als Ganzes. Die lokal installierte Version ist kein Cloud-Dienst und gehört nicht in den Bericht. Nach unserer Einschätzung lohnt es sich trotzdem, Entwicklung und Freigabe für beide Linien gleich aufzusetzen: Der Prüfer sieht Ihren Entwicklungsprozess, und zwei Prozesse sind doppelte Arbeit. In Werbung und Angeboten sollte klar sein, welche Version testiert ist.

Nachweise, die Hersteller vorbereiten sollten

Mögliche Lücken bei Herstellern von Praxissoftware

• Fernwartung ohne Protokoll. Ursache: Der Support nutzt ein Fernwartungswerkzeug auf dem Praxis-PC und von dort den Zugang zur Anwendung. Wirkung: Zugriffe auf Kundendaten lassen sich weder belegen noch melden, und das Werkzeug fehlt als Dienstleister im Verzeichnis nach SSO-04. Abhilfe: Support-Zugriffe nur über einen eigenen, protokollierten Weg in der Anwendung.
• Export nie getestet. Ursache: Bisher hat keine Praxis gekündigt. Wirkung: Der vertraglich zugesagte Export ist nicht belegt. Abhilfe: Export jährlich mit einem Testmandanten durchführen und protokollieren.
• Kundenkontrollen zu allgemein. Ursache: „Die Praxis sorgt für sichere Endgeräte“. Wirkung: Die Praxis kann die Pflicht nicht umsetzen und nicht belegen. Abhilfe: konkrete Anforderungen an den Praxis-PC mit unterstützten Versionen und Prüfhinweisen in den Leitlinien für Kunden.