Medizinproduktehersteller nutzen zunehmend Cloud-Dienste, die wir in diesem Artikel als Medical Cloud bezeichnen.
Erfahren Sie, welche Möglichkeiten Hersteller haben, um Medical Clouds zu nutzen und dennoch die regulatorischen Anforderungen z.B. an den Datenschutz zu erfüllen.
Möglichkeiten für den Einsatz einer Medical Cloud
a) Beispiele für Cloud-Dienste im Gesundheitswesen
Der große Hype ist vorbei: Das Cloud-Computing ist im Alltag der Unternehmen angekommen. Gartner spricht davon, dass das Cloud-Computing den Pfad der Erleuchtung erreicht hat.
Für das Gesundheitswesen, das manchen Trends eher zögerlich folgt, gewinnt das Cloud-Computing an Bedeutung. Zahlreiche Einsatzfelder bieten sich für Medical Clouds an:
- Datenspeicherung für Medical Apps und stand-alone Software (z.B. klinische Informationssysteme und klinische Register)
- Webservices, die Berechnungen anbieten:
- Berechnung von Wechselwirkungen und Kontraindikationen von Arzneimitteln
- Bilderkennung (Onkologie, Pathologie)
- Molekulardiagnostik
- Abrechnung
- Software-Anwendungen, die vollständig 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 |
Regulatorische Anforderungen an Medical Clouds
a) Medizinprodukterecht
Sobald die Software ein Medizinprodukt ist, müssen die Hersteller beweisen, dass die Produkte die grundlegenden Anforderungen der MDD bzw. die allgemeinen Sicherheits- und Leistungsanforderungen der MDR erfüllen. Dazu zählen die Forderungen nach:
- Risikomanagement (ISO 14971)
- „State-of-the-art“ Software-Lebenszyklusprozessen (Entwicklung, Wartung) einschließlich Software-Verifizierung und Software-Validierung (IEC 62304)
- „State-of-the-art“ IT-Security
- Gebrauchstauglichkeit (IEC 62366)
- Marktüberwachung (“Post-Market-Surveillance“)
- Qualitätsmanagementsystem (zumindest Rumpf-QMS)
Besonders bei Medical Clouds werden die Hersteller häufig auch zu Betreibern. Entsprechend sind die Anforderungen z.B. der MPBetreibV einzuhalten.
Zusätzliche Anforderungen ergeben sich, falls die Firma nicht nur der Hersteller, sondern auch der Betreiber der Software ist. Dies gilt insbesondere, wenn dieser Betrieb (z.B. Rechenzentrumsbetrieb, Support) in den Anwendungsbereich („Scope“) des Qualitätsmanagementsystems fällt. Dann muss die Computer-Software, die für die Erbringung dieser Dienstleistung verwendet wird, validiert werden (ISO 13485:2016 Kapitel 4.1.6).
Lesen Sie hier mehr zur Validierung von Computersystemen.
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.
Lesen Sie hier mehr zu den Anforderungen der MDR an Software.
b) Datenschutzrecht
Zusätzlich zum Medizinprodukterecht müssen Hersteller und Betreiber die Anforderungen an den Datenschutz erfüllen. Das Bundesdatenschutzgesetz (BDSG) verbietet die Speicherung personenbezogener Daten, wenn keine Rechtsgründe wie die Einwilligung der Betroffenen dies ermöglichen:
„Die Verarbeitung ist nur rechtmäßig, wenn mindestens eine der nachstehenden Bedingungen erfüllt ist: […]
Die betroffene Person hat ihre Einwilligung zu der Verarbeitung der sie betreffenden personenbezogenen Daten für einen oder mehrere bestimmte Zwecke gegeben;“
„Alle Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person (im Folgenden „betroffene Person“) beziehen; als identifizierbar wird eine natürliche Person angesehen, die direkt oder indirekt, insbesondere mittels Zuordnung zu einer Kennung wie einem Namen, zu einer Kennnummer, zu Standortdaten, zu einer Online-Kennung oder zu einem oder mehreren besonderen Merkmalen identifiziert werden kann, die Ausdruck der physischen, physiologischen, genetischen, psychischen, wirtschaftlichen, kulturellen oder sozialen Identität dieser natürlichen Person sind;“
„Besondere Kategorien personenbezogener Daten“ wie Gesundheitsdaten schätzen die Gesetzgeber als besonders schützenswert ein. Hier genügt die Einwilligung des Betroffenen nicht:
Zusätzlich setzt der Gesetzgeber voraus, dass die Datenspeicherung und Datenverarbeitung „zum Zweck der Gesundheitsvorsorge, der medizinischen Diagnostik, der Gesundheitsversorgung oder Behandlung oder für die Verwaltung von Gesundheitsdiensten erforderlich ist und die Verarbeitung dieser Daten durch ärztliches Personal oder durch sonstige Personen erfolgt, die einer entsprechenden Geheimhaltungspflicht unterliegen“.
Damit ist es ohne weitere Maßnahmen nicht gestattet, Gesundheitsdaten bei einem Cloud-Anbieter zu speichern.
Der Artikel 9 der DSGVO betrifft die „Verarbeitung besonderer Kategorien personenbezogener Daten“.
„Die Verarbeitung personenbezogener Daten, aus denen die rassische und ethnische Herkunft, politische Meinungen, religiöse oder weltanschauliche Überzeugungen oder die Gewerkschaftszugehörigkeit hervorgehen, sowie 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.“
Eine besondere Herausforderung für die Hersteller bildet die europäische Datenschutzgrundverordnung (DSGVO).
Lesen Sie hier mehr zu den Anforderungen an den Datenschutz im Gesundheitswesen.
Herausforderungen für Hersteller und Betreiber
a) Abgrenzung des Medizinproduktes
Dient die Software einer der im §3 MPG 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 (bzw. der Medical Cloud) zählen zum Medizinprodukt und welche zur Laufzeitumgebung?
- 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?
Die Angebote der Cloud-Anbieter alleine stellen nie ein Medizinprodukt dar. Sie können aber Teil eines Medizinprodukts bilden oder eine Laufzeitumgebung dafür bereitstellen.
b) Risikomanagement
Bei Medical Clouds liegen Teile der Software bzw. 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 überhaupt eine ausreichende Kapselung der eigenen Software von der 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-Angriffe)
- 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
Lösungsansätze
Um die gesetzlichen Anforderungen an den Datenschutz zu gewährleisten, bieten sich folgende Konstrukte an:
- Mit dem Cloud-Anbieter muss ein Vertrag über eine Auftragsdatenverarbeitung geschlossen werden. Diese Vereinbarung stellt hohe Anforderungen an den Anbieter.
- Beim Cloud-Anbieter werden nur verschlüsselte Daten gespeichert. Diese Verschlüsselung muss vor der Übertragung in die Cloud erfolgen.
- 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 davon ausgehen, dass Firmen wie Amazon oder Google die Anforderungen für die Auftragsdatenverarbeitung 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.
„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.
d) 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.
e) Medical Cloud: Grenzen ü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 und auch mit dem US-amerikanischen Recht vergleichbar ist, 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.
Lesen Sie hier mehr zum Einsatz und den Besonderheiten von Medical Apps.
f) Klinische Bewertung
Wie oben beschrieben unterscheidet man verschiedene Cloud-Services, die im Rahmen von klinischen Bewertungen unterschiedlich zu berücksichtigen sind:
- Bei einer reinen Datenspeicherung sollte die klinische Bewertung anhand von Performance-Daten (Verifizierung) erfolgen.
- Für eine Medical Cloud die nur IaaS bereitstellt, ist eine klinische Bewertung nur auf Ebene des Produkts möglich.
- Herausfordernd sind klinische Bewertungen von „Computation-Services“ wie sie bei der künstlichen Intelligenz zum Einsatz kommen, beispielsweise neuronale Netzwerke wie sie Googles Tensorflow bereitstellt.
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, und auf Supportanfragen reagierte Amazon offensichtlich auch 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.
Da haben der Hersteller und der Betreiber bei ihrem Risikomanagement wohl nicht sauber gearbeitet.
Die Auslagerung von medizinischen Daten und Applikationen in die sog. Cloud wird of aus Kostengründen betrieben.
Das Problem an Firmen/Diensten wie Amazon, Google, etc… ist, dass es dort keine Ansprechpartner gibt, die sich um individuelle Kundenprobleme individuell kümmern. Es wird kein Unterschied beim Emailsupprt per Kontakformular gemacht, ob ein Hobbyfotograf nicht auf seine Bilder zugreifen kann oder ob Kliniken keinen Zugriff auf wichtige Systeme haben.
Analog wäre das das Fukushima der Medizin IT…
EInige harte Diskussionen müßten die Folge sein.
Cloud-Computing im Gesundheitswesen ist möglich – wenn die Daten so verschlüsselt werden, dass die Administratoren der Server keine Möglichkeit haben, auf die Daten im Klartext zuzugreifen. Dies funktioniert – Arztpraxen arbeiten bereits seit über zwei Jahren mit der Arztsoftware RED Medical, die genau dieses Prinzip umgesetzt hat.