Software als Medizinprodukt: Neue Anforderungen durch die IVDR

Für die Europäische Verordnung über In-vitro-Diagnostika (IVDR) gibt es 101 Erwägungsgründe. Nach den gro­ßen Medizinskandalen und zuletzt durch den Skandal um Brustimplantate sah sich die Europäische Kommission (EC) verpflichtet, die Gesundheitspolitik der Europäischen Union (EU) und die damit verbundenen Gesetze zu überarbeiten. Wesentliche Erwägungsgründe lagen dabei in der Erhöhung der Sicherheit von Medizinprodukten und In-vitro-Diagnostika. So wurden durch die europäische Medizinprodukteverordnung (MDR) und die IVDR die alten Verordnungen (MD und IVD) bereits 2017 abgelöst, mit der Besonderheit, dass diese als Richtlinien unmittelbar gelten und keiner Übersetzung in das deutsche Recht bedürfen. Damit ergeben sich direkte Auswirkungen auf das deutsche Medizinprodukte-Recht: Das Medizinproduktegesetz (MPG) wurde durch das Medizinprodukterecht-Durchführungsgesetz (MPDG) abgelöst; die Betreiberverordnung (MPBetreibV) wurde angepasst und die Medizinprodukte-Sicherheitsplanverordnung (MPSV) durch die Medizinprodukte-Anwendermelde- und Informationsverordnung (MPAMIV) durch eine veränderte Meldepflicht für schwerwiegende Vorkommnisse ersetzt. Die Medizinprodukte-Verordnung (MPV) und die Verordnung über klinische Prüfungen von Medizinprodukten (MPKPV) wurden ersatzlos aufgehoben und ihre Inhalte in MDR und MPDG überführt.

Wesentliche Änderungen

Damit ergeben sich eine Reihe von Änderungen für Hersteller und Anwender von Medizinprodukten bzw. In-vitro-Diagnostika. Wesentliche Neuerungen für Hersteller ergeben sich aus der Einteilung der Produkte in Risikoklassen (A–D) anstelle der bisherigen „Positiv-Listen“, womit unmittelbar der Anteil an überwachten Produkten steigt. Die Einführung der einmaligen Produktnummer (UDI) zur Rückverfolgbarkeit, veränderte Leistungsbewertungen und Konformitätsbewertungsverfahren sowie die Notwendigkeit, die klinische Validität eines Produktes zu belegen, sind eine große Herausforderung.

Eine gänzlich neue Anforderung für Hersteller resultiert aus dem erweiterten Geltungsbereich der IVDR: So definiert die IVDR nicht nur Begriffe wie Reagenz, Reagenzprodukt, Kalibrator, Kontrollmaterial, Kit, Instrument, Apparat und Gerät, sondern auch Software oder Softwaresys­teme als Medizinprodukt, sofern diese vom Hersteller zur In-vitro-Untersuchung von aus dem menschlichen Körper stammenden Proben, einschließlich Blut- und Gewebespenden, bestimmt sind. Deshalb kann auch eine Software durchaus ein IVD im Sinne der IVDR werden. Da die IVDR Eigenherstellungen (LDTs) zukünftig wesentlich erschwert, sind viele Laboratorien bereits in der Umsetzung der IVDR für ihre typischen Eigenentwicklungen wie LC-MS/MS-Methoden im Bereich des Therapeutic Drug Monitoring oder der Immunhistologie mit eigenen Antikörpern begriffen.

Einordnung als SaMD

Viele Laboratorien haben im Laufe der Zeit Software entwickelt: Diese reichen vom einfachen Excel-Tool bis hin zu komplexen Lösungen zur Abbildung von diagnostischen Pfaden, der Unterstützung oder sogar vollautomatisierten Befundung. Häufig sind diese in die jeweiligen Labor­informationssysteme (LIS) eingebettet.

Diese Software wird als „Software as a Medical Device“ (SaMD) eingeordnet, da sie nicht Bestandteil eines Geräts (Analyzers) ist. Weil LIS und Work Area Managers (WAM) nach MEDDEV (MEDDEV 2.1) nicht per se Medizinprodukte sind, stellt sich die Frage, ob die Software-Entwicklungen der Labore der IVDR unterliegen. Die MEDDEV führt klärend aus: Wenn die Software dazu bestimmt ist, für eine Person mehrere Ergebnisse von verschiedenen IVD-Geräten zu erfassen und gemeinsam auszuwerten, um Informationen zu liefern, die unter die Definition eines IVD-Medizinproduktes fallen, wird diese Software als ein IVD an sich betrachtet.

Eng ausgelegt bedeutet dies, dass im LIS hinterlegte Algorithmen z. B. zur Abschätzung der GFR (CKDEPI), die Zusammenfassung von Ergebnissen der Liquoranalytik in Reiber-Diagrammen oder die automatisierte Befundung von z. B. TSH, fT4 und fT3-Messungen durchaus unter die IVDR fallen können. Da diese Algorithmen typischerweise nicht von den LIS-Anbietern verkauft, sondern durch die Labore selbst „programmiert“ werden, werden die Labore für diese Software zu Herstellern.

Gerade bei hochmodernen Technologien wie NGS sind Laboratorien oft auf vollständig selbstentwickelte Software-Tools angewiesen oder müssen kommerzielle IVD-Software auf spezifische Bedürfnisse hin durch Parametrierung und Konfiguration mit der Gefahr des nicht zweckkonformen Betriebs anpassen. Damit ist die Grenze zwischen Eigenentwicklung und modifizierter kommerzieller IVD-Software schwer zu ziehen (wenn die Modifikationen die Zweckbestimmung verändern, liegt sicher eine Eigenherstellung vor). Zudem gibt es gerade bei bio­informatischen Pipelines (Calling, Annotation, Variantenbewertung) Hybridformen, in denen Software-Komponenten kommerzieller Hersteller übernommen und Software-Eigenentwicklungen integriert werden.

IVDR-konforme Softwareentwicklung

Dass solche Softwareanwendungen als Eigenherstellungen ebenfalls IVDR-konform entwickelt und betrieben werden müssen, ist neu, weshalb hier nur sehr wenige Labore auf eigene Erfahrungen zurückgreifen können. Die IVDR weist bei Softwareeigenentwicklungen im Gegensatz zu Laboranalytik in Eigenherstellung nicht auf einschlägige Normen wie die DIN EN ISO 15189 hin. Auch die MDCG-2019-11 nennt keinen Normbezug zur Softwareentwicklung. Daher haben Laboratorien grundsätzlich die Freiheit, einen für sie passenden Entwicklungsrahmen zu definieren.

Für Laboratorien ist es sinnvoll, sich zunächst einen Überblick darüber zu verschaffen, welche Anwendungen innerhalb des Labors im Einsatz sind. Analog zu den klassischen Eigenherstellungen muss für Software ebenfalls geprüft werden, ob es kommerzielle Alternativen gibt. Falls dies nicht der Fall ist, müssen Laboratorien prüfen, ob sie die Voraussetzungen für eine Eigenentwicklung erfüllen, z. B. bezüglich des Qualitäts- und Risikomanagements. Entscheidend ist zu Beginn der Herstellung eine klar umrissene Zweckbestimmung. Diese sollte den geplanten Einsatz widerspiegeln und zum einen umfassend, aber auch gegen mögliche kommerzielle Produkte klar abgegrenzt sein.

Damit ergibt sich durch die Einstufung auch, ob die MDR oder die IVDR anzuwenden ist.

Die Risikoklassifizierung sieht vier Risikoklassen vor: A, B, C und D, wobei D die höchste Klasse bezeichnet. Nach der Klassifizierung muss der Anhang I der IVDR auch für Software beachtet werden. Es empfiehlt sich die Verwendung einer einheitlichen technischen Dokumenta­tion, die die Besonderheiten von Software berücksichtigt.

Handreichungen

Im Rahmen der Ad-hoc-Kommission „In vitro-Diagnostik“ der Arbeitsgemeinschaft der Wissenschaftlichen Medizinischen Fachgesellschaften (AWMF) hat sich eine Subgruppe mit den Fragen zur IVDR-konformen Softwareentwicklung befasst und Hinweise zur Validierung von Software veröffentlicht, aus denen in diesem Artikel zitiert wird [1].

Die DIN EN 62304 kann als Grundlage für eine Software-Validierung dienen. Diese schlägt einen an den Risikoklassen orientierten Validationsprozess im Sinne eines Software-Lebenszyklus-Prozesses vor. Die Schritte umfassen dabei einen Entwicklungsplan, die Anforderungsspezifikation, die Architektur, das Design, die Modul-Implementierung, die Integrationsprüfung, die Systemprüfung, die Software-Freigabe und die -Wartung.

Bei der Entwicklung sind die Anforderungen bezüglich IT-Sicherheit zunehmend wichtig; hier können die Norm ISO 27001 und der Leitfaden der Medical Device Coordination Group (MDCG 2019-16 Guidance on Cybersecurity for Medical Devices) Unterstützung bieten.

Die Subgruppe Software der AWMF merkt an, dass es in der Praxis hilfreich sein kann, komplexere Algorithmen oder bioinformatische Pipelines in einzelne Funktionalitäten (Module) zu unterteilen. Nicht jeder Teil eines Algorithmus oder einer Pipeline erfüllt Aufgaben, die unter die Regularien der IVDR fallen und somit eine sehr umfassende Dokumentation und Testung nach IEC 62304 Klasse B bzw. C erfordern. Durch die Modularisierung ergeben sich auch Vorteile bei Änderungen an der Software, sodass nicht zwingend der ganze Algorithmus bzw. die vollständige Pipeline erneut zu validieren ist.

Da die IVDR zwar für die klassischen IVDs Verweise auf die DIN EN ISO 15189 enthält, für den Bereich der Software aber keinen Normbezug herstellt, können die oben erwähnten Normen Anwendung finden, müssen es aber nicht. So können Labore auch alternative Standards für die Softwareentwicklung verwenden, z. B. GAMP V.

Insgesamt stellt die IVDR durch die Ausweitung ihres Geltungsbereichs auf Software Laboratorien vor erhebliche Aufgaben. Insbesondere da es bislang wenig Erfahrungen und wenig praktische Hinweise in Form sogenannter „Guidance Documents“ der MDCG gibt, sollten Labore diese Freiheiten nutzen und schlanke Validationsstrategien etablieren.