Medical Cloud und Cloud-Computing im Gesundheitswesen

Medizinprodukte- und IVD-Hersteller verwenden zunehmend Cloud-Dienste:

1. Hersteller nutzen cloudbasierte Software-Anwendungen, so wie andere Unternehmen etwa cloudbasierte ERP- oder ALM-Systeme einsetzen.
2. Hersteller verwenden Cloud-Plattformen, um darauf eigene Software-Anwendungen zu betreiben. Bieten sie diese Anwendungen den Kunden an, z. B. Krankenhäusern oder Patienten, so bezeichnen wir diese cloudbasierten Plattformen in diesem Artikel als Medical Cloud.

Erfahren Sie, welche Möglichkeiten Hersteller haben, um Cloud-Dienste wie Medical Clouds zu nutzen und dennoch die regulatorischen Anforderungen an z. B. den Datenschutz zu erfüllen.

Möglichkeiten für den Einsatz einer Medical Cloud

a) Beispiele für Cloud-Dienste im Gesundheitswesen

Selbst im Gesundheitswesen, das manchen Trends eher zögerlich folgt, ist das Cloud-Computing „angekommen“:

• Cloudbasierte Datenspeicher für Software-Anwendungen wie Medical Apps, klinische Informationssysteme und klinische Register
• Webservices, die Berechnungen anbieten:
  • Berechnung von Wechselwirkungen und Kontraindikationen von Arzneimitteln
  • Bilderkennung (Onkologie, Pathologie)
  • Molekulardiagnostik
  • Abrechnung
• Vollständige Software-Anwendungen, die komplett in die Cloud gewandert sind:
  • Webbasierte klinische Informationssysteme
  • Elektronische Gesundheits- und Patientenakten
  • Online Tools, z. B. zur Berechnung von Scores
  • Medizinische Suchmaschinen
  • Online-Werkzeuge für die klinische Forschung

b) Medical Cloud as PaaS, IaaS, SaaS

Bei Cloud-Diensten unterscheidet man verschiedene Varianten:

Cloud Service	Angebot des Cloud-Dienstleisters	Beispiel
Infrastructure as a Service (Iaas)	Alternative zum eigenen Server („on premise“): Cloud ersetzt eigene Hardware (CPU, Speichersysteme und Netzwerk)	Amazon EC2
Platform as a Service (PaaS)	Alles außer dem eigenen Code steht bereit, z. B. Hardware, Datenbank, Applikationsserver, Entwicklungsumgebung	Google App Engine, SAP Hana, Amazon Elastic Beanstalk
Software as as Service (SaaS)	Cloud-Anbieter stellt Software zur direkten Nutzung zur Verfügung	Salesforce, Microsoft Office 365, Google Apps

Diese Cloud Services unterscheiden sich dadurch, welche Schichten des „Software-Stacks“ in der Verantwortung des Cloud-Anbieters bleiben und welche in der eigenen Verantwortung als Kunde liegen (s. Abb. 1).

Regulatorische Anforderungen an Medical Clouds

a) Medizinprodukterecht

Das Medizinprodukterecht wird relevant, sobald die Software ein Medizinprodukt bzw. die Software ein IVD ist. Dann müssen Hersteller nachweisen, dass ihre Produkte die allgemeinen Sicherheits- und Leistungsanforderungen der MDR bzw. IVDR erfüllen. Dazu zählen die Forderungen nach:

• Risikomanagement (ISO 14971)
• Software-Lebenszyklusprozessen (Entwicklung, Wartung) einschließlich Verifizierung und Validierung (IEC 62304)
• IT-Security
• Gebrauchstauglichkeit (IEC 62366-1)
• Marktüberwachung (Post-Market-Surveillance)
• Qualitätsmanagementsystem

Falls die Firma nicht nur der Hersteller, sondern auch der Betreiber der Software ist, muss sie neben der genannten Betreiberverordnung weitere Anforderungen beachten. Dies gilt insbesondere, wenn dieser Betrieb (z. B. eines Rechenzentrums, von Support) in den Anwendungsbereich („Scope“) des Qualitätsmanagementsystems fällt. Dann muss der Hersteller die Computer-Software, die für die Erbringung dieser Dienstleistung verwendet wird, validieren (ISO 13485:2016 Kapitel 4.1.6).

Das Medizinprodukterecht kennt keine dedizierten Anforderungen an Medical Clouds. Allerdings erwähnt die MDR, dass Hersteller verschiedene Plattformen und Betriebssysteme bei der Software-Verifizierung bzw. Validierung berücksichtigen müssen.

b) Datenschutzrecht

Zusätzlich zum Medizinprodukterecht müssen Hersteller und Betreiber die Anforderungen an den Datenschutz erfüllen. Die Datenschutzgrundverordnung (DSGVO) sowie das Bundesdatenschutzgesetz (BDSG) verbieten die Speicherung personenbezogener Daten, wenn keine Rechtsgründe wie die Einwilligung der Betroffenen dies ermöglichen.

„Besondere Kategorien personenbezogener Daten“ wie Gesundheitsdaten schätzen die Gesetzgeber als besonders schützenswert ein. Hier ist eine explizite Einwilligung der Betroffenen notwendig:

Die Verarbeitung […] von genetischen Daten, biometrischen Daten zur eindeutigen Identifizierung einer natürlichen Person, Gesundheitsdaten oder Daten zum Sexualleben oder der sexuellen Orientierung einer natürlichen Person ist untersagt [, es sei denn, die] betroffene Person hat in die Verarbeitung der genannten personenbezogenen Daten für einen oder mehrere festgelegte Zwecke ausdrücklich eingewilligt […]

DSGVO Artikel 9 (1) und (2) a)

Damit ist eine Argumentation mit „berechtigtem Interesse“ für Gesundheitsdaten nicht möglich.

c) Weitere Rechtsgebiete

Als Anbieter und Nutzer von Cloud-Diensten sind weitere Gebiete des IT-Rechts relevant:

• Allgemeine Geschäftsbedingungen
• Mietrecht, denn viele Cloud-Verträge werden juristisch als Mietverträge betrachtet
• Compliance-Recht, wie die Anforderung an eine rechtskonforme Unternehmensführung und ein Unternehmens-Risikomanagement

Auch bei Software-Anwendungen, die nicht als Medizinprodukt zählen, sind die Anforderungen an die IT-Sicherheit relevant, z. B. die EU-NIS 2 Richtlinie.

Betreiben Firmen auf der Cloud auch IoT-Anwendungen, sollten sie die Anforderungen des EU Data Acts beachten.

Herausforderungen für Hersteller und Betreiber

a) Abgrenzung des Medizinprodukts

Dient die Software einer der im § 2 (1) MDR genannten Zweckbestimmungen, ist sie ein Medizinprodukt. Die Hersteller müssen genau abgrenzen, was Teil des Medizinprodukts ist und was nicht. Dazu sollten sie folgende Fragen präzise beantworten:

• Handelt es sich um ein Medizinprodukt oder um mehrere?
  (z. B. Server, iOS-App, Android-App)
• Sind die Produkte als Medizinprodukt oder als Zubehör zu klassifizieren?
• Welche Teile des Servers (oder der Medical Cloud) zählen zum Medizinprodukt und welche zur Laufzeitumgebung?
  (s. Abbildung 2)
• Was sind die konkreten Anforderungen an die Laufzeitumgebung?
  Diese Festlegung verlangt u. a. die IEC 62304 in Kapitel 5.2.
• Welche Software-Bestandteile zählen zur Laufzeitumgebung und welche als SOUP?

Das Angebot eines Cloud-Anbieters stellt nie ein Medizinprodukt dar. Es kann aber einen Teil eines Medizinprodukts bilden oder eine Laufzeitumgebung dafür bereitstellen.

b) Risikomanagement

Bei Medical Clouds liegen Teile der Software bzw. der Infrastruktur außerhalb der Kontrolle des Herstellers. Er muss dennoch im Risikomanagement den Nachweis führen können, dass Risiken, die sich durch Änderungen durch den Cloud-Anbieter ergeben, beherrschbar und akzeptabel sind.

Diese Abschätzung setzt voraus, dass die Software-Architektur eine ausreichende Kapselung der eigenen Software von der Software der Medical Cloud gewährleistet.

Diese Risikofolgenabschätzung benötigt der Hersteller/Betreiber für die Computerized System Validation CSV.

Typische Risiken beim Arbeiten mit Medical Clouds werden verursacht durch:

• Mangelnde Verfügbarkeit der Cloud (z. B. technische Probleme, Hacker-Angriff)
• Mangelnde Performanz
• Fehlkonfiguration oder Fehlbedienung der Medical Cloud Services durch den Kunden
• Verlust der Vertraulichkeit
• Änderung der Schnittstellen (z. B. API)
• Verlust der Datenintegrität oder Datenverlust, z. B. als Folge von Hacker-Angriffen, Update des Cloud-Service durch den Anbieter oder den Kunden, Fehler bei Restore

c) Gewährleistung des Datenschutzes bei cloudbasierten Diensten

Lösungsansätze

Um die gesetzlichen Anforderungen an den Datenschutz zu gewährleisten, bieten sich folgende Konstrukte an:

1. Mit dem Cloud-Anbieter muss ein Vertrag über eine Auftragsdatenverarbeitung geschlossen werden. Diese Vereinbarung stellt hohe Anforderungen an den Anbieter.
2. Beim Cloud-Anbieter werden nur verschlüsselte Daten gespeichert. Die Verschlüsselung muss vor der Übertragung in die Cloud erfolgen.
3. Beim Cloud-Anbieter werden keine personenbezogenen Daten gespeichert. Dies kann dadurch gelingen, dass kein Personenbezug mehr herstellbar ist.

Problem mit US-Anbietern

Man kann derzeit nicht sicher davon ausgehen, dass Firmen wie Amazon oder Google die Anforderungen an den Datenschutz erfüllen, weil nicht ausgeschlossen werden kann, dass US-amerikanische Behörden den Zugriff auf die Daten erzwingen. Das gilt auch dann, wenn die Daten in europäischen Rechenzentren gespeichert werden. Allerdings werden diese Risiken inzwischen als beherrschbar betrachtet und akzeptiert, insbesondere wenn einer der zuvor genannten Lösungsansätze genutzt wird.

„Privacy by Design“

Die Europäische Datenschutzgrundverordnung verlangt „Privacy by Design“. Beispielsweise müssen die Hersteller die Produkte so entwickeln, dass

• unnötige Daten nicht erfasst werden,
• die Zustimmung der Patienten nachvollziehbar belegt werden kann und
• die Daten problemlos gelöscht werden können, wenn ein Patient die Einwilligung zurückzieht.

Diese Anforderungen wirken sich direkt auf das Produkt und seine Software-Architektur aus. Meist ist es schwer, Produkte zu nachträglich ändern, um diese Anforderungen zu erfüllen.

d) Qualitätsmanagement und Dokumentenlenkung

Die ISO 13485 verlangt von den Herstellern die Dokumentenlenkung.

Weil Atlassian, ein Anbieter cloudbasierter Lösungen, in der Vergangenheit Probleme mit der Verfügbarkeit der Daten hatte und sogar Daten verloren gingen, verlangen einige Benannte Stellen von den Herstellern jetzt Konzepte, wie diese

• den Schutz der Daten vor Verlust und
• den Schutz vor Nichtverfügbarkeit der Daten

gewährleisten und damit die Anforderungen der ISO 13485 auch in solchen Problemfällen erfüllen.

e) Gleichzeitig Hersteller und Betreiber

Viele Hersteller von Medical Apps sind sich nicht bewusst, dass sie durch das Abspeichern von Daten in einer Medical Cloud auch zum Betreiber werden. Entsprechend kennen und erfüllen sie die regulatorischen Anforderungen nicht.

f) Medical Cloud: Grenzüberschreitende Angebote

Im Gegensatz zu physischen Produkten gelingt es nur schwer, die Verwendung von Cloud-Diensten und Apps räumlich zu begrenzen. Daher müssen Hersteller darauf achten, wie sie eine Inverkehrbringung in Märkte verhindern, für die sie die regulatorischen Anforderungen nicht einhalten können oder wollen.

Während das Mediziprodukterecht europaweit sehr einheitlich ist und auch mit dem US-amerikanischen Recht vergleichbar, unterscheiden sich die Anforderungen an den Datenschutz zwischen den einzelnen Ländern deutlich. Das gilt trotz der DSGVO auch für die europäischen Nationalstaaten.

g) Support

Die Verfügbarkeit vieler Cloud-Services ist höher als die der eigenen Server. Doch es gibt weitere Herausforderungen: Beispielsweise hatte eine Firma, die Patientenmonitoringsysteme betreibt, ein wirkliches Problem. Sie hatte ihr System bei Amazon gehostet. Leider schien dieser Amazon-Service nicht zu funktionieren; auf Supportanfragen reagierte Amazon offensichtlich nicht. “Life of our patients is at stake – I am desperately asking you to contact” flehte der Hersteller. Aber keine Antwort von Amazon. Grotesk war auch der zugehörige Diskussions-Thread — gehostet auf den Rechnern von Amazon.

Fazit und Zusammenfassung

„Increasing adoption, low returns, huge potential“, so fasst McKinsey den Stand der Cloud Computings zusammen. Das gilt inzwischen auch für das Gesundheitswesen.

Die gesetzlichen Anforderungen an das Cloud Computing im Gesundheitswesen zu erfüllen, ist besonders herausfordernd. Das betrifft nicht nur das Datenschutz-, sondern auch das Medizinprodukterecht.

Doch zunehmend herrscht Klarheit darüber, wie Medizinproduktehersteller und Betreiber diese Anforderungen erfüllt können. Dazu trägt vielleicht auch dieser Artikel bei sowie die weitere Unterstützung des Johner Instituts bei.

---

Änderungshistorie

• 2024-04-04: Umfangreiche Änderungen
  • Alle Referenzen auf MPG, MDD und altes BDSG entfernt und neue Gesetze (MDR, IVDR, Data Act) referenziert
  • Einleitung mit Gartner-Hype-Cycle entfernt
  • Bild mit Software-Stack eingefügt
  • Teilkapitel mit Dokumentenlenkung ergänzt
• 2017-12-05: Erste Version des Artikels veröffentlicht