Medizinprodukte mit Patienten-Cloud: den Cloud-Teil für das C5-Testat zuschneiden

Diese Seite richtet sich an Hersteller von Medizinprodukten, deren Geräte Daten mit Patientenbezug in eine Cloud übertragen, die der Hersteller selbst betreibt oder betreiben lässt. Ob § 393 SGB V für Ihre Kunden und damit für Sie greift, erklärt die Seite § 393 SGB V. Für Hersteller mit Sitz im Ausland siehe internationale Anbieter; dort steht ein Beispiel zur Fernüberwachung von Patienten zu Hause.

C5 und Medizinprodukterecht: zwei getrennte Fragen

Ein C5-Testat beantwortet Fragen der Informationssicherheit eines Cloud-Dienstes. Ob die Cloud-Software selbst ein Medizinprodukt oder Teil eines Medizinprodukts ist, welcher Risikoklasse sie angehört und welche Pflichten aus der europäischen Medizinprodukteverordnung (MDR) folgen, beantwortet es nicht, und umgekehrt ersetzt eine Konformitätsbewertung nach MDR kein C5-Testat. Diese Seite behandelt nur den C5; die Einordnung nach Medizinprodukterecht ist gesondert zu prüfen. Auch Datenschutz deckt der C5 nach der FAQ des BSI nicht ab.

Das Beispiel: eine Bildcloud für Ultraschallgeräte

Fiktives Beispiel, kein Kunde. Ein Hersteller von Ultraschallgeräten bietet Praxen und Kliniken einen Cloud-Dienst an, in den die Geräte Untersuchungen hochladen. Die Architektur:

• Gerät in der Praxis oder Klinik, angeschlossen an deren Netz. Es meldet sich mit einem Gerätezertifikat aus der Zertifizierungsstelle des Herstellers am Cloud-Dienst an.
• Empfangsdienst in der Cloud, der Untersuchungen annimmt und dem richtigen Kunden zuordnet.
• Befundung im Browser für Ärztinnen und Ärzte, auch von unterwegs.
• Bildarchiv je Kunde mit Aufbewahrungsfristen, die der Kunde festlegt.
• Firmware-Verteilung: signierte Updates für die Geräte über denselben Dienst.
• Betrieb auf einer Cloud-Plattform in einer Region in Deutschland.

Wer was verantwortet: Hersteller, Plattform, Kunde

Entscheidung 1: Das Gerät bleibt draußen, seine Identität kommt hinein

Nach unserer Einordnung gehört das Gerät nicht zum Cloud-Dienst: Es steht beim Kunden, der Kunde betreibt es und bindet es an sein Netz an. Kriterien, die sich auf seinen Betrieb beziehen würden, lassen sich aber nur mit einer Begründung ausschließen, die der Katalog zulässt, und nie, weil der Hersteller dort keine Kontrollen eingerichtet hat (Abschnitt 3.4.3). Der Betrieb gehört deshalb als vorausgesetzte Kundenkontrolle in die Systembeschreibung.

Die Identität des Geräts ist ein anderer Fall. Der Cloud-Dienst vertraut einem Gerät, weil es ein Zertifikat des Herstellers vorlegt. CRY-08.01B verlangt Verfahren für die sichere Ausstellung von Public-Key-Zertifikaten, die der Anbieter für seine eigenen Systemkomponenten oder sein Personal ausstellt, einschließlich einer Prüfung der Identität vor der Ausstellung. Ob Geräte beim Kunden in diesem Sinn Systemkomponenten des Dienstes sind, beantwortet der Katalog nicht ausdrücklich. Unsere Empfehlung: die Ausstellung der Gerätezertifikate wie eigene Systemkomponenten behandeln und in der Systembeschreibung so darstellen. Dazu gehört der Widerruf: Wird ein Gerät verkauft, zurückgenommen oder als verloren gemeldet, muss sein Zertifikat gesperrt werden, sonst lädt ein fremdes Gerät in das Archiv des alten Kunden. Für kompromittierte Schlüssel gilt CRY-13. Wie Schlüssel und Zertifikate insgesamt prüffähig werden, siehe Themengebiet CRY.

Entscheidung 2: Freigaben nach Medizinprodukterecht und nach C5 in einem Ablauf

Ist die Cloud-Software Teil eines Medizinprodukts, durchläuft eine Änderung nach Medizinprodukterecht eine eigene Bewertung. Der C5 verlangt daneben, Änderungen einer Risikobeurteilung zu unterziehen, die ihre Auswirkungen auf den gesamten Dienst bewertet, und bei hohem Risiko vor der Bereitstellung Minderungsmaßnahmen zu ergreifen (DEV-06.01B, .02B), sowie Freigaben vor der Bereitstellung in der Produktionsumgebung (DEV-10). Nach unserer Einschätzung lohnt ein gemeinsamer Ablauf: ein Änderungsticket mit beiden Bewertungen und beiden Freigaben. Dann gibt es für jede Änderung im Typ-2-Zeitraum einen Beleg, und die Bewertung nach Medizinprodukterecht ist im Ticket sichtbar, ohne dass der C5-Prüfer sie beurteilt.

Schwierig wird es bei dringenden Sicherheitskorrekturen. DEV-15.01B verlangt Verfahren für Ausnahmen vom Änderungsmanagement, einschließlich Notfalländerungen, damit die Risiken angemessen gemindert werden. Legen Sie vorher fest, wie eine Notfallkorrektur im Cloud-Dienst mit der Bewertung nach Medizinprodukterecht zusammenpasst, und dokumentieren Sie jede Ausnahme mit Datum und Begründung. Firmware für die Geräte läuft durch denselben Prozess, auch wenn das Gerät selbst nicht im Scope steht. Wie Änderungen insgesamt prüffähig werden, siehe Themengebiet DEV.

Entscheidung 3: Große Bildarchive bei Vertragsende

Ein Bildarchiv wächst über Jahre. Kündigt ein Kunde, muss er seine Daten mitnehmen können. Drei Kriterien greifen hier zusammen:

• PI-01.02B verlangt technische Mittel, mit denen Kunden ihre Daten extrahieren können. Soweit Datenvolumen, Format oder Architektur eine Extraktion durch den Kunden nicht praktikabel machen, stellt der Anbieter angemessene Extraktionsdienste bereit. Bei großen Bildarchiven ist das nach unserer Einschätzung der realistische Weg.
• PI-02 verlangt vertragliche Regeln für die Bereitstellung der Daten nach Vertragsende, unter anderem Format, Fristen und den Zeitpunkt der Löschung.
• PI-03 verlangt, dass die Löschung den Vertrag einhält und so dokumentiert wird, dass der Kunde einen Nachweis erhält. Ausnahmen sind nur zulässig, wenn eine gerichtliche Anordnung sie erfordert oder sie zur Erfüllung bekannter künftiger finanzieller und rechtlicher Verpflichtungen nötig sind (PI-03.01B).

Welche Aufbewahrungsfristen für die Bilder gelten, bestimmt der Kunde nach seinen eigenen Pflichten. Der Vertrag sollte so gestaltet sein, dass er sie nach dem Export selbst erfüllen kann; das ist rechtlich gesondert zu prüfen.

Nachweise, die Medizinproduktehersteller vorbereiten sollten

Mögliche Lücken bei Medizinprodukteherstellern