Open Source als Medizinprodukt

Insbesondere universitäre Einrichtungen veröffentlichen regelmäßig medizinische Software als Open Source. Dies lässt Zweifel aufkommen, ob es sich bei dieser Open-Source-Software um ein Medizinprodukt handelt und welche regulatorischen Risiken und (Produkt-)Haftungsrisiken damit verbunden sind.

Dieser Artikel bietet einen schnellen Überblick.

1. Rolle von Open-Source-Software in medizinischen Geräten

Open-Source-Software kann sowohl das medizinische Gerät als auch ein Teil davon sein. Folgende Konstellationen sind möglich: Die Open-Source-Software ist

1. eine speziell für das Medizingerät entwickelte Komponente (z. B. ein KI-Modell mit zugehöriger API) oder
2. eine handelsübliche Komponente, die im medizinischen Gerät verwendet wird, z. B. eine Bibliothek oder
3. das Medizinprodukt selbst

2. Rechtliche Einordnung

Eine Haftung entsteht insbesondere dann, wenn ein Medizinprodukt in Verkehr gebracht wird. Daher müssen zwei Fragen geklärt werden:

1. Wann gilt ein Produkt als Medizinprodukt?
2. Wann erfolgt ein Inverkehrbringen?

A. Wenn ein Produkt als Medizinprodukt gilt

Nicht die Funktionalität eines Produktes entscheidet über dessen Eignung (Entscheidung, ob es sich um ein Medizinprodukt handelt oder nicht), sondern sein Verwendungszweck.

Dadurch vermeiden Entwickler von Open-Source-Software, dass ihre Arbeitsergebnisse beispielsweise für folgende Zwecke als Medizinprodukt gelten:

• Das Produkt dient der Forschung oder der Dokumentation von Forschungsergebnissen
• Zur Entwicklung medizinischer Produkte soll/darf Software eingesetzt werden
• Für die Schulung wird Open-Source-Software verwendet

Besonders hilfreich ist auch der Hinweis, dass es sich bei der Software nicht um ein Medizinprodukt handelt und nicht dazu bestimmt ist, Krankheiten und Verletzungen zu diagnostizieren, zu lindern, zu behandeln oder vorherzusagen.

B. Wenn es zu einer Inverkehrbringung kommt

Die MDR definiert in Artikel 2 (§§ 27 und 28), was ein Inverkehrbringen ist:

Jede Erstlieferung eines Produkts, sei es gegen Bezahlung oder unentgeltlich […] zum Vertrieb, Verbrauch oder zur Nutzung auf dem Unionsmarkt im Rahmen einer kommerziellen Tätigkeit;

§§ 27 und 28, Artikel 2 MDR

Der Konsum oder die Verwendung eines Medizinprodukts in einer Arztpraxis oder einem Krankenhaus gilt als gewerbliche Tätigkeit, auch wenn diese Tätigkeit nicht auf Erwerbszweck ausgerichtet ist.

Ist die Open-Source-Software nur für den Einsatz innerhalb der Gesundheitseinrichtung vorgesehen, in der sie entwickelt wurde, kommt eine Eigenproduktion gemäß MDR/IVDR Artikel 5, Abschnitt 5 in Betracht.

3. Gesetzliche Verpflichtungen

A. Medizinprodukterecht

Gilt die Open-Source-Software als Medizinprodukt, das in Verkehr gebracht wird oder werden soll, müssen deren Hersteller alle regulatorischen Anforderungen an Medizinprodukte erfüllen.

Diese Anforderungen betreffen sowohl das Medizinprodukt als auch die Organisation, die das Medizinprodukt auf den Markt bringt.

Die wichtigsten grundlegenden Sicherheits- und Leistungsanforderungen (GSPR) für Software betreffen:

Darüber hinaus ist ein Qualitätsmanagementsystem gemäß ISO 13485 bzw. Anhang IX der MDR/IVDR erforderlich. Dazu gehört auch ein Post-Market-Überwachungssystem.

B. Weitere gesetzliche Anforderungen

Zusätzlich und unabhängig vom Medizinprodukterecht müssen Hersteller möglicherweise andere „horizontale“ Vorschriften einhalten, wie zum Beispiel:

Die Anwendbarkeit und relevanten Anforderungen dieser Vorschriften hängen von der Rolle der Open-Source-Entwickler ab.

Das KI-Gesetz stellt keine Anforderungen an Open-Source-KI-Systeme.

4. Auswertungs- und Anwendungsbeispiele

A. Vorteile von Open-Source-Medizinsoftware

Die Entwickler von Open-Source-Medizinprodukten argumentieren mit folgenden Vorteilen:

• Open Source fördert Innovationen und bringt Innovationen schnell ans Krankenbett.
• Die Entwicklungsergebnisse stehen jedem zur Verfügung, unabhängig von seinen finanziellen Möglichkeiten.
• Der Transparenz- und Community-Ansatz hilft, Fehler schnell zu finden und zu beheben, was die Patientensicherheit fördert.
• Es besteht beispielsweise kein Interessenkonflikt wie bei herstellerfinanzierten klinischen Studien.

B. Herausforderungen bei Open-Source-Medizingeräten

Die Entwicklung von Open-Source-Medizinprodukten muss spezifische Herausforderungen bewältigen:

• Erforderlich ist eine Organisation mit einem (zertifizierten) Qualitätsmanagementsystem und allen regulatorischen Rollen wie dem QMB und dem PRRC.
• Die Fähigkeiten müssen auch regulatorische Anforderungen außerhalb der Entwicklung erfüllen, beispielsweise im Qualitäts- und Risikomanagement, im Usability Engineering und in Regulatory Affairs.
• Die hohen Post-Market-Kosten müssen über Jahre anfallen und finanziert werden, zumindest solange ein Produkt noch auf dem Markt ist.
• Da keine Verkäufer-Käufer-Beziehung besteht, ist die Kommunikation mit Kunden/Nutzern schwieriger, was unter anderem das Risikomanagement und die Überwachung nach dem Inverkehrbringen anspruchsvoller macht.
• Personalfluktuation, beispielsweise bei Doktoranden, macht es noch schwieriger, Kompetenzen langfristig zu sichern.
• Die Kontrolle (Erstellung, Überprüfung, Freigabe) von Artefakten wie Dokumenten und Quellcode erfordert besondere Aufmerksamkeit in einer Community, die keiner Organisation entspricht.

5. FAQ

A. Wie vermeide ich als Open-Source-Entwickler eine Klage?

Das Risiko, verklagt zu werden, lässt sich nicht ausschließen, die Wahrscheinlichkeit aber schon. Das Risiko ist umso größer

• ein möglicher Rechtsverstoß offensichtlicher ist,
• höher die wirtschaftliche Relevanz des Produkts (z. B. für Wettbewerber) und
• der Beklagte ist finanziell leistungsfähiger.

Andererseits ist es hilfreich, den Zweck und die Ansprüche sehr konsistent und transparent zu formulieren und die Anwendbarkeit regulatorischer Anforderungen zu recherchieren und einzuhalten.

B. Muss ich ein CE-Zeichen anbringen? Wenn ja, wo?

Mit der CE-Kennzeichnung erklärt der Inverkehrbringer des Produkts die Konformität mit den geltenden EU-Richtlinien oder -Verordnungen. Diese Kennzeichnung ist nur zulässig und zugleich erforderlich, wenn das Produkt in den Geltungsbereich einer dieser Richtlinien oder Verordnungen fällt und dort die CE-Kennzeichnung erforderlich ist.

C. Was muss ich bei der Nutzung von Github beachten?

IT-Systeme zur Versions- und Konfigurationsverwaltung sowie zum Betrieb von CI/CD-Pipelines gelten als computergestützte Systeme im Rahmen des QM-Systems und müssen daher einer computergestützten Systemvalidierung unterzogen werden.

Diese Systeme müssen die gesetzlich und normativ geforderte Dokumentenkontrolle gewährleisten, allerdings ist dies eher eine Frage der korrekten Konfiguration und weniger der Leistungsmerkmale dieser Systeme.

D. So dokumentieren Sie ein Open-Source-SaMD für die FDA-Zulassung

Für Open-Source-SaMD gelten die gleichen regulatorischen Anforderungen wie für alle anderen SaMD. Dazu gehören:

• Technische Dokumentation vergleichbar mit MDR
• Als Teil davon eine Cybersicherheitsdatei
• Qualitätsmanagement nach 21 CFR Teil 820
• Eine Freigabe der FDA, zum Beispiel im Rahmen einer 510(k)- oder De-novo-Zulassung.

e. Wer kann mir helfen?

Die (Software-)Experten des Johner Instituts helfen bei allen Fragen rund um die Dokumentation, Genehmigung und Einrichtung eines Managementsystems. Gleiches gilt für die vorgeschriebenen Tests wie Usability-Tests, Pen-Tests und klinische Tests.

6. Fazit und Zusammenfassung

Viele universitäre Einrichtungen unterschätzen den Aufwand, Medizinprodukte gesetzeskonform zu entwickeln, in Verkehr zu bringen und zu überwachen. Professionelles Software-Engineering ist eine notwendige, aber bei weitem nicht ausreichende Voraussetzung.

Es kann hilfreich sein, Forschung und Entwicklung zu trennen und sich der Kommerzialisierung nicht grundsätzlich zu verschließen, zumal sich dies nicht mit dem Open-Source-Gedanken ausschließt. Denn Gutes für Patienten zu tun kostet nicht nur Zeit, sondern leider auch Geld.

Ähnliche Beiträge