Medizintechnik und Pharma

Medizin-Software entwickeln – darauf kommt es an

26 Februar 2018
| |

Die Anforderungen für die Entwicklung medizinischer Software sind durch die EU drastisch verschärft worden. Das ist kein Grund zur Panik – ein Leitfaden zeigt, worauf es wirklich ankommt. Das Wichtigste daraus habe ich hier zusammengefasst.

Die Digitalisierung macht auch vor dem Gesundheitswesen nicht halt – mit allen Chancen, Risiken und Herausforderungen. Als Folge davon wird auch Software in diesem Bereich immer wichtiger. Aus regulatorischer Sicht lassen sich dabei im Wesentlichen sogenannte Embedded-Software und Stand-alone-Software unterscheiden. Erstere ist ein integraler Bestandteil eines Medizinprodukts, letztere ist selbst ein Medizinprodukt, z.B. eine medizinische App. Erst kürzlich hat der europäische Gesetzgeber die Anforderungen für Medizinprodukte drastisch verschärft. Deshalb gibt es Befürchtungen, dass gerade kleinere und mittlere Herstellerunternehmen diesen Anforderungen nicht mehr gerecht werden können.

Herausforderung durch Normen in der Medizintechnik

Hier kommt die kürzlich erschienene zweite Publikation der Deutschen Gesellschaft für Biomedizinische Technik (DGBMD) aus dem Bereich „Normen in der Medizintechnik“ gerade recht. Sie befasst sich mit der Entwicklung und Herstellung medizinischer Software und soll gerade kleineren und mittleren Unternehmen einen Leitfaden für die Umsetzung der Anforderungen an die Hand geben.

Auf Grund der Erfahrungen von Zühlke in diesem Bereich kam der VDE auf mich zu, um das Kapitel der Entwicklung von Medizinischer Software von der Idee zum Produkt als Autor mit zu begleiten. Herausgekommen ist eine Übersicht über die modernen Prinzipien der agilen Softwareentwicklung unter den Rahmenbedingungen der regulierten Entwicklung eines Medizinprodukts.

Die wichtigsten Anforderungen im Überblick

Die Normen im Bereich der Medizintechnik stellen hohe Anforderungen an den Entwicklungsprozess. Die wichtigsten für die App-Entwicklung sind aus meiner Sicht folgende:

  • Planung der Aktivitäten vor der Durchführung
    Für Medizinprodukte gilt die Forderung nach einem geregelten und geplanten Vorgehen, das alle Punkte der Normen erfüllt. Alle Aktivitäten müssen vor der Durchführung geplant und diese Planung dokumentiert werden.
  • Detaillierungsgrad ist abhängig vom Safety-Beitrag der Software
    Das Risikomanagement und die daraus ermittelte Patientengefährdung sind ein zentraler Bestandteil um die Detaillierung und Intensität der Aktivitäten zu bestimmen.
  • Design Input vor Design Output
    Vor der Durchführung von Aktivitäten oder der Erzeugung von Design Output, wie z.B. Source-Code wird der Design Input benötigt. Oder etwas salopper formuliert: Ohne die Anforderungen, was entwickelt werden soll, kann weder Source-Code geschrieben noch ein Programm verifiziert werden
  • Änderungs- / Change Management
    Ein freigegebenes Konfigurationselement (z.B. eine Dokumentation oder ein Source-Code) darf nur nach vorher freigegebener Änderungsanforderung modifiziert werden. Dabei muss für alle betroffenen Konfigurationselemente die Vorgeschichte bis zum aktuellen Stand rückverfolgbar sein.
  • Zwang zur Dokumentation
    Einer der Grundsätze bei der Entwicklung von Medizinprodukten ist, dass die Planung, die Durchführung sowie die Ergebnisse dokumentiert werden müssen. Kurz und prägnant: „Funktionierende und getestete Software ohne Dokumentation ist wertlos.“

Dokumentation muss sein

Am Beispiel der Dokumentation wird dabei deutlich, dass die Normen in der Medizintechnik nicht nur Anforderungen stellen, sondern auch gewisse Freiheitsgrade zulassen. Grundsätzlich muss am Ende der regulierten Entwicklung einer Software immer eine konsistente Dokumentation vorliegen. Meistens kommt hier eine grafische Darstellung im Stil des V-Modells zum Einsatz.

Dokumentation in der Medizintechnik

Auf der linken Seite des V werden die Anforderungen detailliert aufgelistet und implementiert – von der Zweckbestimmung über die Spezifikation des Gesamtsystems bis zur Design-Spezifikation. Auf der rechten Seite werden den Spezifika-tionen entsprechende Testfälle gegenübergestellt und damit die Einhaltung der Anforderungen gewährleistet. Die begleitenden Prozesse des Risikomanagements und der Usability führen auf den verschiedenen Detaillierungsebenen zu Anforderungen und Nachweisen.

Viele Freiheitsgrade trotz strenger Normen

Aus dieser Darstellung wird oft der falsche Schluss gezogen, dass das V-Modell oder wasserfallähnliche Prozesse als Entwicklungsprozesse vorgeschrieben sind. Dabei lassen die Normen in der Medizintechnik sehr viele Freiheitsgrade für den Entwicklungsprozess, die auch den modernen Anforderungen an Software-Entwicklung entsprechen. Weder die EN 62304 noch die FDA schreiben ein Lebenszyklusmodell vor, vielmehr benennt die EN 62304 den agilen Entwicklungsprozess als mögliche Vorgehensweise.

Auszug-norm-en62304

Freiheiten wie diese machen es auch weiterhin für kleine und mittlere Unternehmen möglich, medizinische Software zu entwickeln. Gestiegen ist lediglich die Anforderung an das Know-how und die Organisation. Gemeinsam mit weiteren Co-Autoren stelle ich dieses Thema in ausführlicherer Form auch auf zwei Veranstaltungen der DGBMD vor. Es würde mich freuen Sie auf einer dieser Veranstaltungen treffen und mit Ihnen über Ihre Projekt zu sprechen:
VDE Veranstaltung Frankfurt
MedTec Stuttgart

Gerne entwickeln wir auch für Sie Softwarelösungen für die Medizinische Anwendung – von der Idee bis zum Produkt! Kontaktieren Sie mich hierzu gerne per Mail

Business Solution Manager

Matthias Wufka

Kommentare (0)

×

Updates

Schreiben Sie sich jetzt ein für unsere zwei-wöchentlichen Updates per E-Mail.

This field is required
This field is required
This field is required

Mich interessiert

Select at least one category
You were signed up successfully.