Herausforderungen in einem regulierten Umfeld Software-Entwicklung für Medizinprodukte #####

Software übernimmt zunehmend zentrale Aufgaben in der Medizintechnik. Damit einher gehen viele Vorteile für die Geräteanwender: Innovative Funktionen, Flexibilität der Einsatzmöglichkeiten und die Fähigkeit zur Vernetzung...

Herausforderungen in einem regulierten Umfeld

Software übernimmt zunehmend zentrale Aufgaben in der Medizintechnik. Damit einher gehen viele Vorteile für die Geräteanwender: Innovative Funktionen, Flexibilität der Einsatzmöglichkeiten und die Fähigkeit zur Vernetzung mit klinischen Systemen sind nur einige. Software kann aber auch für einen Großteil der Fehler in Medizingeräten verantwortlich gemacht werden. Deshalb ist bei der Entwicklung derartiger Software bewusstes und sorgfältiges Vorgehen notwendig.

Software befindet sich heute in einer Vielzahl von Medizinprodukten. Angefangen von Kleinstgeräten wie Insulin-Pens über die klassischen bildgebenden Verfahren wie Computertomographie (CT) oder Magnetresonanztomographie (MR) bis hin zu komplexen, verteilten Informationssystemen wie Bildarchiven und Krankenhaus-Informationssystemen übernimmt Software wesentliche und mitunter sicherheitskritische Aufgaben. Diese Computerisierung der Medizingeräte hat Gründe:

  • Produkte lassen sich kostengünstiger herstellen, wenn vormals elektrisch oder mechanisch gesteuerte Funktionen von Mikrocontrollern ausgeführt werden.
  • Die Anforderungen an die Vernetzbarkeit medizinischer Geräte nehmen zu.
  • Innovative Funktionen lassen sich oftmals durch Software überhaupt erst realisieren.

Da Medizinprodukte in aller Regel unmittelbar Einfluss auf das Wohlergehen der Patienten nehmen, sollte größte Sorgfalt bei der Erstellung von Software für Medizingeräte selbstverständlich sein. Dennoch zeigen Statistiken des Bundesinstituts für Arzneimittel und Medizinprodukte (BfArM) eine erschreckende Anzahl an Fehlern, die auf Software-Komponenten in den Geräten zurückzuführen sind. Das BfArM musste feststellen, dass Software-Fehler die größten Verursacher von Design- und Konstruktionsfehlern sind. Von 1586 Risikomeldungen im Zeitraum 1.1.2005 bis 31.12.2007 waren 355 (22,4 %) durch Software-Fehler hervorgerufen [1].

Die Gründe für diese Fehler sind vielfältig. Eine aktuelle Studie des Fraunhofer Instituts für Experimentelles Software-Engineering [2] kommt zu dem Schluss, dass die größte Fehlerquelle in der Erhebung und im Umgang mit den System-Anforderungen liegt. Hinzu kommen falsch umgesetzte Funktionen bei Programmbestandteilen, die von Dienstleistern zugeliefert werden. Insgesamt entsteht der Eindruck, dass moderne Methoden des Software-Engineering und der Qualitätssicherung – entgegen aller regulatorischen Vorschriften – in der Medizintechnik-Branche nicht konsequent genug umgesetzt werden.

Fehlerbehafteter Software kann auf systematische Weise durch die Definition und Einhaltung von geeigneten Entwicklungsprozessen vorgebeugt werden. Gerade bei Medizinprodukten werden eine Vielzahl von Anforderungen an diese Prozesse gestellt: Neben der Beschreibung der Vorgehensweisen müssen auch die Vorschriften der Zulassungsbehörden berücksichtigt werden. Auch Normen und Standards wollen eingehalten sein. Und nicht zuletzt soll die Entwicklung Anforderungen an die Effizienz genügen. Grund genug, sich mit diesen Anforderungen und den Konsequenzen daraus näher zu beschäftigen.

Regulatorische Anforderungen an Prozesse

Medizinprodukte unterliegen weltweit vielfältigen gesetzlichen Regelungen. Um der Bedeutung, die Medizingeräten für das Wohl der Patienten zukommt, Rechnung zu tragen, müssen diese Produkte von einer offiziellen Stelle zugelassen werden, bevor sie in der Praxis zur Anwendung kommen dürfen.

Die Vorschriften, denen die Entwicklung von Medizingeräten unterliegt, lassen sich grob in zwei Kategorien einteilen:

  • Vorschriften, die sich auf die Funktion der Produkte beziehen.
  • Vorschriften, die sich auf die Prozesse bei der Entwicklung der Produkte beziehen.

In die erste Kategorie fallen beispielsweise technische Anforderungen zur elektrischen Sicherheit von Geräten, zum Umgang mit ionisierender Strahlung oder auch zur Gebrauchstauglichkeit. Diese Anforderungen sind mehr oder weniger spezifisch für die Art des Gerätes. Sie sind in Form von technischen Normen formuliert und erfordern die Orientierung am „Stand der Technik“. Der Nachweis, dass die Anforderungen erfüllt wurden, kann prinzipiell durch eine technische Prüfung des Produktes geführt werden.

In der zweiten Kategorie finden sich Regelungen, die sich auf den Prozess beziehen, der zur Entwicklung eingesetzt wurde. Hierfür typisch sind die Forderung nach einem angemessenen Qualitätssicherungssystem und die Anwendung der Methoden des Risikomanagements. Die Erfüllung dieser Forderungen kann nur durch den Nachweis der Konformität des (notwendigerweise schriftlich festgelegten) Entwicklungsprozesses erfolgen. Hierzu sind Audits des Prozesses unabdingbar.

Die Regulatorien für Medizinprodukte unterscheiden in aller Regel nicht zwischen mechanischen, elektronischen oder software-technischen Komponenten. Aufgrund der Besonderheiten von Software – sie unterliegt eben keinen physikalischen Beschränkungen – sind für die Software-Entwicklung vorwiegend die Vorschriften der zweiten Kategorie von besonderer Relevanz.

Die Beurteilung der Reife eines Prozesses und damit der Fähigkeit eines Herstellers, systematisch qualitativ hochwertige Software zu erstellen, kann mit Hilfe eines Reifegradmodells erfolgen. Ein Beispiel für ein solches Modell ist die ISO 15504 [5], die für verschiedene Prozessbereiche die Ermittlung des Reifegrades erlaubt (Bild 3). Die ISO 15504 beschreibt im Wesentlichen ein Verfahren für eine einheitliche Bewertung von Prozessen in der Software-Entwicklung. Diese Bewertung wird in jedem Bereich durch eine Maßzahl, den Reifegrad, zusammengefasst. Die Reifegrade liegen dabei zwischen 0 (keine definierte Vorgehensweise) und 5 (definierte und überwachte Prozesse, die einer stetigen Verbesserung unterliegen). Der Reifegrad lässt nicht nur einen Rückschluss auf die Prozesstreue zu, sondern beurteilt auch, wie gut der Prozess die speziellen Herausforderungen bei der Software-Entwicklung adressiert. Dazu dienen Referenzmodelle, die Kriterien für die inhaltliche Güte des Prozesses liefern.