Kliniksoftware aus der Cloud: was Hersteller vor dem C5-Testat entscheiden

Diese Seite richtet sich an Hersteller von Kliniksoftware, die ihre Software als Cloud-Dienst anbieten, etwa für OP-Planung, Pflegedokumentation oder Patientenportale. Ob und wie § 393 SGB V für Krankenhäuser und ihre Dienstleister greift, erklärt die Seite § 393 SGB V; diese Seite wiederholt das nicht und ist keine Rechtsberatung. Für KI-Software in Kliniken mit Modellanbieter und Inferenz siehe KI im Gesundheitswesen, für Hersteller von Praxissoftware Praxissoftware-Anbieter.

Das Beispiel: OP- und Ressourcenplanung für Klinikverbünde

Fiktives Beispiel, kein Kunde. Ein Hersteller bietet eine Software für die Planung von OP-Sälen, Personal und Material als SaaS an. Die Architektur:

• Anwendung im Browser, mandantenfähig, betrieben auf einer Cloud-Plattform in einer Region in Deutschland; ein Mandant je Klinik.
• Zwei dedizierte Instanzen für große Klinikverbünde, die das vertraglich verlangt haben: eigene Datenbank und eigene Netzsegmente, aber dieselbe Software, dieselbe Bereitstellung und dasselbe Betriebsteam.
• Anbindung an das Krankenhausinformationssystem (KIS): Patientenstammdaten und OP-Anforderungen kommen als HL7-Nachrichten vom Kommunikationsserver der Klinik, geplante und tatsächliche OP-Zeiten gehen zurück. Die Verbindung läuft über einen verschlüsselten Standorttunnel zwischen Kliniknetz und einem Schnittstellendienst in der Cloud.
• Anmeldung der Klinikbeschäftigten über den Identitätsanbieter der Klinik (Single Sign-on).
• Betrieb mit Bereitschaft rund um die Uhr, weil die Kliniken auch nachts und am Wochenende operieren.

Wer was verantwortet: Hersteller, Plattform, Klinik

Die rechte Spalte gehört als korrespondierende Kundenkontrollen (CUEC) in die Systembeschreibung (Abschnitt 3.4.5.1 Nr. 7). Wie Sie solche Pflichten so formulieren, dass die Klinik sie umsetzen und belegen kann, zeigt die Seite korrespondierende Kriterien für Kunden.

Entscheidung 1: Wo endet der Prüfungsgegenstand an der KIS-Schnittstelle?

Nach unserer Einordnung am Tunnelendpunkt in der Cloud. Alles, was der Hersteller dort betreibt, gehört in den Prüfungsgegenstand: der Tunnelendpunkt, der Schnittstellendienst und die Regeln, welche Nachrichten er annimmt. Zwei Kriterien beschreiben, was dort zu belegen ist:

• PI-01 verlangt für Schnittstellen, über die IT-Systeme von Kunden auf den Dienst zugreifen, unter anderem standardisierte Kommunikationsprotokolle mit angemessener Authentisierung, Verschlüsselung über nicht vertrauenswürdige Netze und Mechanismen, die die Integrität der übertragenen Daten prüfen (PI-01.01B Nr. 1, 2 und 4).
• COS-04 verlangt, dass jeder Netzperimeter durch Sicherheitsgateways kontrolliert wird und netzübergreifende Zugriffe auf einer Sicherheitsbeurteilung beruhen, die die Anforderungen der Kunden berücksichtigt (COS-04.01B und .02B).

Kommunikationsserver, Tunnelendpunkt und Firewall im Kliniknetz betreibt die Klinik. Sie stehen als vorausgesetzte Kundenkontrollen in der Systembeschreibung; der Katalog nennt zu COS-04 selbst korrespondierende Kriterien für Kunden, die Kontrolle an den Perimetern der Netze, für die der Kunde verantwortlich ist. Der Prüfer prüft diese Kontrollen bei der Klinik nicht, nur ihre sachgerechte Darstellung, und weist im Bericht darauf hin, dass die Kriterien nur bei wirksamen Kundenkontrollen erfüllt werden.

Unsere Empfehlung: Halten Sie in einem Schnittstellenblatt je Klinik fest, welche Nachrichtentypen in welche Richtung fließen, wer welchen Endpunkt betreibt und wer Zugangsdaten und Zertifikate des Tunnels erneuert. Dieses Blatt ist Nachweis für PI-01 und zugleich die Grundlage der Kundenkontrollen.

Entscheidung 2: Anmeldung über den Identitätsanbieter der Klinik als Zusatzkriterium?

Für Kliniksoftware lohnt sich der Blick auf zwei Zusatzkriterien. PI-01.02AC verlangt Schnittstellen für Identitätsanbieter des Kunden mit einem standardisierten Protokoll, PI-01.03AC eine klare Dokumentation dieser Schnittstellen für das Fachpersonal des Kunden. Im Beispiel ist beides vorhanden, weil die Kliniken Single Sign-on verlangen. Nach unserer Einschätzung kann der Hersteller diese beiden Unterkriterien mit wenig Mehraufwand in den Prüfungsumfang nehmen. Welche Zusatzkriterien Sie aufnehmen, entscheiden Sie selbst; nehmen Sie nur einzelne auf, ist die Auswahl in der Systembeschreibung zu begründen (Abschnitt 3.4.3). Die Konten des Klinikpersonals bleiben auch dann eine Kundenkontrolle.

Entscheidung 3: Gehören dedizierte Instanzen in denselben Bericht?

Nach unserer Einordnung ja, wenn sie Teil des angebotenen Dienstes sind. Die Systembeschreibung nennt Name, Typ und Umfang der bereitgestellten Cloud-Dienste (Abschnitt 3.4.5.1 Nr. 1). Steht dort nur die gemeinsame Instanz, erhalten die beiden Klinikverbünde einen Bericht, der ihre Instanz nicht abdeckt. Drei Folgen sollten Sie vor der Prüfung klären:

1. Grundgesamtheit. Patches, Änderungen und Berechtigungsprüfungen laufen auf allen Instanzen. Zieht der Prüfer in einer Typ-2-Prüfung Stichproben, braucht er die vollständige Liste aller Fälle; Ihr Nachweisregister sollte deshalb je Kontrolle zeigen, welche Instanzen dazugehören (siehe Nachweisregister).
2. Patch-Management. OPS-27 verlangt unter anderem, Patches in Wartungsfenstern zu planen und vor der Produktion in einer Nicht-Produktionsumgebung zu testen, mit der Möglichkeit, auf frühere Versionen zurückzugehen (OPS-27.01B Nr. 2 und 3). Wer für dedizierte Instanzen eigene Wartungsfenster vereinbart, braucht für jede Instanz den Beleg, dass der Patch im vereinbarten Zeitrahmen ankam (OPS-28).
3. Trennung. Auch eine dedizierte Instanz teilt sich Plattform, Bereitstellungswerkzeuge und Betriebszugänge mit den anderen. Die Trennung gehört deshalb in dasselbe dokumentierte Schichtenmodell nach OPS-30, mit einer Risikobeurteilung, die mindestens jährlich überprüft wird (OPS-31).

Entscheidung 4: Wiederanlauf im 24/7-Betrieb

Eine Klinik plant ihre OP-Säle auch dann, wenn die Software ausfällt. Dafür braucht sie Angaben des Herstellers. GC-03 verlangt, dass der Anbieter sachverständigem Personal der Kunden auf Anfrage Angaben zu den Wiederanlaufparametern zur Verfügung stellt: maximal tolerierbare Ausfallzeit und RTO, maximal zulässiger Datenverlust (RPO), Zeit bis zur Aufnahme des Notbetriebs, Notbetriebsniveau und Zeit bis zum Regelbetrieb. Diese Angaben sollen der Klinik ihre eigene Business Impact Analyse ermöglichen. Was die Rahmenbedingung GC-03 und die übrigen Rahmenbedingungen im Einzelnen verlangen, zeigt die Seite Rahmenbedingungen. Zwei Punkte sind bei Kliniksoftware besonders wichtig:

• Das Ausfallverfahren der Klinik, etwa ein Ausdruck des Tagesplans und ein Ablauf für Notfall-OPs, ist ihre eigene Kontrolle und gehört als vorausgesetzte Kundenkontrolle in die Systembeschreibung.
• BCM-04.01B verlangt, dass an den mindestens jährlichen Tests der Kontinuitätspläne betroffene Cloud-Kunden und relevante Dritte beteiligt sind. Laden Sie eine Klinik zu einem Wiederanlauftest ein und protokollieren Sie ihre Rückmeldung. Wie Kontinuitätstests insgesamt prüffähig werden, siehe Themengebiet BCM.

Für Vorfälle gilt Ähnliches: OPS-24 verlangt, dass der Anbieter Kunden über den Status von Vorfällen informiert, die sie betreffen. Der Katalog nennt dazu als korrespondierendes Kriterium für Kunden, dass die Meldungen ankommen und an die zuständige Stelle weitergeleitet werden. Für eine Klinik heißt das: ein Kontakt, der auch nachts erreichbar ist.

Nachweise, die Hersteller von Kliniksoftware vorbereiten sollten

Mögliche Lücken bei Herstellern von Kliniksoftware