Mit einem Medizinprodukt in die Cloud? Welche Gedanken sich die Hersteller vorher machen (müssen).

Wir können unsere Gesundheit zunehmend selbst durch den Einsatz von Software unterstützen. Von der Kniegymnastik (etwa companion patella) über die Nikotin-Entwöhnung (beispielsweise Nichtraucherhelden) bis zur Therapie von Depression (zum Beispiel elona therapy) – es sind bereits viele Webanwendungen und Apps auf dem Markt. Ist eine Software vom Hersteller für therapeutische oder diagnostische Zwecke vorgesehen, dann handelt es sich rechtlich um ein Medizinprodukt. Damit muss der Hersteller alle dafür geltenden Gesetze und folglich alle Vorgaben der verschiedenen Normen beachten.

Wie bei vielen Webanwendungen und Apps werden dabei häufig große Datenmengen als Content bereitgestellt, erfasst und ausgewertet. Aufgrund der hohen Verfügbarkeit und der einfachen Skalierbarkeit greifen viele Hersteller von Medizinprodukten für die Speicherung und Verarbeitung dieser Daten auf externe Anbieter zurück. Neben den Hyperscalern (unter anderem Amazon mit AWS, Microsoft mit Azure und Google mit Cloud Platform) sind auch europäische Anbieter wie die Telekom mit der Healthcare-Cloud auf dem Markt zu finden.

In diesem Blog-Beitrag werden die Erwartungen an die Normen und Verordnungen dargestellt und gruppiert, so dass in einem übergreifenden Prozess ihre Erfüllung geprüft und dokumentiert werden kann. Dabei wird auch auf Erfahrungen aus der Pharmawelt zurückgegriffen, die bei vielen Cloud-Anbietern bereits in Whitepapers oder Guidelines für den Einsatz von digitalen Medizinprodukten unter regulierten Bedingungen beschrieben sind.

Welche Besonderheiten gelten für Software mit medizinischem Hintergrund?

Oberstes Ziel bei der Betrachtung von medizinischer Software ist die Sicherheit und Unversehrtheit der Patientinnen und Patienten, in diesem Fall der User der Software. Bei der Software sowie bei der Cloud-Nutzung stehen die Daten im Fokus. Diese betreffen drei wichtige Bereiche:

• Verfügbarkeit: Was ist, wenn Daten nicht zur Verfügung stehen? Beispielsweise ein wichtiges Untersuchungsergebnis, das kurz vor einer OP fehlt?
• Vertraulichkeit: Was ist, wenn Daten öffentlich werden? Etwa eine unangenehme Krankheit wird im Kollegium bekannt?
• Unveränderbarkeit: Was ist, wenn Daten manipuliert werden? Zum Beispiel ein Blutzuckerwert wird um das Doppelte erhöht?

Der Gesetzgeber hat daher aus gutem Grund besondere Verfahren zur sicheren Gestaltung von Software vorgesehen. Diese Verfahren, die sich in der medizinischen Softwareentwicklung bewährt haben, lassen sich jedoch nicht so einfach auf einen Cloud-Anbieter übertragen.

Die wichtigsten Herausforderungen dabei sind:

• Updates von internen Systemen können vom Hersteller selbst gesteuert werden. Aber was ist mit automatisierten Updates von Cloud Services ohne Vorankündigung?
• Lokale Lieferanten oder auch die interne IT-Abteilung können auditiert werden, um die Einhaltung der Prozesse zu prüfen. Aber was ist mit einem internationalen Cloud-Anbieter?
• Wie kann der Umgang mit besonders schützenswerten personenbezogenen Daten konform zur europäischen Datenschutzverordnung und – im Fall von DiGAs (Apps auf Rezept) – auch zum Sozialgesetzbuch gestaltet werden?

Trotz aller Herausforderungen und Fragen bleibt festzustellen: Die Nutzung von Cloud Services ist durch die geltenden Gesetze und Normen nicht verboten! Viele Pharmaunternehmen, Hersteller von Medizinprodukten sowie medizinische Labore nutzen bereits Cloud Services und wenden dabei viele Prinzipien der Computersystem-Validierung an.

Begriffsverwirrung: Unterschiede zwischen Qualifizierung, Verifizierung und Validierung

Je nach Art der Nutzung von Cloud-Diensten steigen die Anforderungen an die Nachweise der Prüfungen. Grundsätzlich geht es immer um Vertrauen. Welches Maß an Vertrauen muss der Hersteller nachweisen, damit Cloud Services genutzt werden können? Diese Frage werde ich im Folgenden anhand der relevanten Kapitel der ISO EN 13485 „Medizinprodukte – Qualitätsmanagementsysteme – Anforderungen für regulatorische Zwecke“ erläutern.

Bei der Qualifizierung muss lediglich nachgewiesen werden, dass eine Umgebung die Software ausreichend unterstützt. Dies ist der Fall, wenn die Cloud als Infrastruktur im Sinne von ISO EN 13485 Kapitel 6 genutzt wird. Der Nachweis erfolgt durch die Definition von Anforderungen und Wartungsaktivitäten.

Die Verifizierung geht einen Schritt weiter: Es muss ein objektiver Nachweis erbracht werden, dass ein System, in diesem Fall der Cloud Service, ordnungsgemäß implementiert wurde und somit die Anforderungen erfüllt. Kapitel 7.4 der ISO EN 13485 fordert die Verifizierung von extern bezogenen Dienstleistungen. Ein objektiver Nachweis sind beispielsweise Testfälle, die nach dem 4-Augen-Prinzip erstellt und durchgeführt wurden.

Die hohe Kunst ist dann die Validierung, also der Nachweis, dass ein System den definierten Zweck erfüllt. Ein einfaches Beispiel: Wenn der Cloud Service zwar getestet wurde, um Bilddateien zu speichern, dafür aber eine lange Übertragungszeit benötigt, dann ist der definierte Zweck für den Einsatz während einer schnellen Trainingseinheit in der Anwendung nicht erfüllt. Eine Validierung ist immer dann erforderlich, wenn der Cloud Service als Teil des Medizinproduktes genutzt wird (ISO EN 13485 Kapitel 7.5).

Konkrete Anforderungen an den Cloud Service Provider

Was muss der Hersteller eines Medizinproduktes also tun? Zum Glück gibt es Dokumente der Zentralstelle der Länder für Gesundheitsschutz bei Arzneimitteln und Medizinprodukten (ZLG), die auch von Inspektorinnen und Inspektoren für die Vorbereitung ihrer Audits verwendet werden (Aide-Mémoire ZLG 2022). Dort wird direkt am Anfang Folgendes klar beschrieben: Cloud Services dürfen eingesetzt werden, wenn sichergestellt wird, dass die Cloud Service Provider in der Lage sind, richtig zu handeln und dies mit einer ausreichenden Verlässlichkeit auch tun. Nach der genauen Definition des Cloud-Modells (Private, Community, Public) und der Art der Services (Iaas, Paas, Saas) werden die Risiken von Software und Daten analysiert und formelle Vereinbarungen mit konkreten Verantwortlichkeiten erstellt. Das Risiko nimmt dabei zu, je mehr Kundinnen und Kunden dieselbe Cloud-Umgebung nutzen (Gefahr für die Daten, weniger Einfluss auf Updates). Auch auf der Achse der Infrastruktur für die Plattform zur Software steigt das Risiko und damit der Aufwand für die entsprechenden Nachweise (Qualification – Verification – Validation).

Leider sind die oben genannte ISO EN 13485 und das ZLG-Dokument nicht die einzigen Quellen. Auch in den Normen zur Entwicklung von medizinischer Software (IEC 62304 und IEC 82304), der Technischen Richtlinie TR-03161, dem Good Practice Guide IT Infrastructure ISPE/GAMP und den Whitepapern oder Guidelines zum Einsatz unter regulierten Bedingungen der Cloud Provider selbst finden sich Anforderungen, die sich überschneiden und ergänzen.

Beispiel aus der adesso-Praxis

Wir haben die Anforderungen aus vielen Dokumenten gesammelt und kategorisiert. Unter folgenden Kategorien:

• Company (Zertifikate),
• Product (Dokumentation),
• Operation (Change Management) und
• Processes (Entwicklung)

sind jeweils die Requirements aus allen Quellen zusammengestellt. Während die Grundgedanken häufig gleich sind, unterscheiden sich doch die Details häufig je nach Umfeld und relevanten Normen und Richtlinien. Diese Matrix kann wie eine Audit-Checkliste genutzt werden: Zunächst werden die anwendbaren Anforderungen selektiert. Für jede Anforderung wird dann die vorhandene Umsetzung beschrieben und bewertet, um zusätzliche Aktivitäten zu definieren. Ein finaler Kommentar zur Umsetzung der Aktivitäten schließt die Anforderung ab.

Bei der Erhebung der relevanten Informationen über den Cloud Service Provider empfehlen wir ein gestaffeltes Vorgehen je nach dem Gesamtrisiko. Viele Punkte sind schon über bestehende Zertifikate oder Berichte (ISO EN 9001, ISO/IEC 27001, SOC2+) abgedeckt oder können den Dokumenten der Provider entnommen werden. Wenn notwendig, kann über den Sales-Kontakt des Cloud Service Provider ein Fragebogen ausgefüllt oder eine Onlinebefragung der betroffenen Abteilungen (Remote Audit) vereinbart werden. Ein Besuch vor Ort, der in den Schreckensszenarien häufig genannt wird, ist so in den meisten Fällen zu vermeiden.

Phasenmodell

• Auswahlphase: In der Auswahlphase müssen die Erwartungen in Bezug auf Daten, unterstützte Prozesse und Risiken (Was passiert beispielsweise, wenn ein Bagger die Datenleitung kappt?) definiert werden. Dazu gehört auch die Auswahl des passenden Cloud Service Provider sowie des Deployment-Modells (Private/Hybrid/Public) und des Service-Modells (Iaas/Paas/Saas).
• Einführung: Mit der Einführung werden dann die Verträge aufgesetzt, um die Prozesse beim Cloud Service Provider festzulegen und auch mit Zahlen zu belegen (Service-Level, Key-Performance-Indikatoren/KPIs).
• Nutzungsphase: Während der Nutzungsphase erfolgt das Monitoring der Prozesse mit Hilfe der KPIs und einer jährlichen Prüfung, ob die Verträge eingehalten werden.

Mit diesem Vorgehen kann ein Hersteller von Medizinprodukten zeigen, dass die speziellen Risiken bei der Nutzung von Cloud Services betrachtet und die Anforderungen an die entsprechenden Normen und Verordnungen geprüft wurden.