Entwicklungsprozess und Prozessmodelle

Der Entwicklungsprozess beschreibt, wie die an der Entwicklung beteiligten Rollen (z.B. Requirements Engineers, Programmierer, Architekten, Tester usw.) Inputs in Outputs (z.B. Baupläne, Software, Dokumentation) überführen.

Das „wie“ umfasst die Reihenfolge und die Abhängigkeiten der einzelnen Aktivitäten sowie die Wahl der Methoden.

Ein Beispiel für Methoden sind die Blackbox-Testverfahren zum systematischen Ableiten von Testfällen.

Tipp

Lesen Sie weiter unten, wie Sie redundante Aufwände und Probleme im Audit vermeiden können, wenn Sie den Entwicklungsprozess und den Risikomanagementprozess zusammenlegen.

Prozessmodelle

Die meisten Firmen wie beispielsweise Medizinproduktehersteller arbeiten entweder gemäß einem Wasserfall- oder V-Modell-artigen oder einem agilen Prozessmodell.

Weiterführende Informationen

Lesen Sie hier mehr zur agilen Software-Entwicklung. und zum V-Modell.

Regulatorische Forderungen an Prozesse

Alle relevanten Regularien und Normen fordern ein prozessorientiertes Vorgehen. Bei Medizinprodukten sind dies:

  • Die Medizinprodukterichtlinie und die Medizinprodukteverordnung (MDR) fordert beispielsweise Software-Lebenszyklusprozesse.
  • Die IEC 62304 schreibt fünf Lebenszyklusprozesse wie die Entwicklung und Wartung fest. Auch die ISO 13485 fordert prozessorientiertes Arbeiten, nicht nur aber auch bei der Entwicklung.
  • Auch die ISO 14971 beschreibt einen Risikomanagementprozess (wohlgemerkt Prozess!).
  • Selbst die „Usability-Norm“, die IEC 62366 fordert, dass die Gebrauchstauglichkeit von Medizinprodukten mit Hilfe eine „gebrauchstauglichkeitsorientierten Entwicklungsprozesses“ gewährleistet wird.
  • Die IEC 60601-1 ist v.a. für deren Beispiel eines Entwicklungsprozesses, der dem V-Modell sehr gleicht:

Entwicklungsprozess gemäß IEC 60601-1

Abb. 1: Entwicklungsprozess gemäß IEC 60601-1

Keine(!) dieser Regularien fordert allerdings ein konkretes Prozessmodell.

Umsetzung der Anorderungen an Entwicklungsprozesse

Gleich für welches Prozessmodell Sie sich entscheiden, Sie müssen

  1. sich für eines entscheiden (zumindest pro Projekt) und dies auch dokumentieren,
  2. nach diesem Prozessmodell auch arbeiten und
  3. dabei die von den Regularien vorgeschriebenen Aktivitäten durchführen.

Die Abbildung 2 gibt Ihnen einen Überblick über diese Aktivitäten.

V-Modell nach Johner

Abb. 2: Aktivitäten im Entwicklungsprozess

Diese Abbildung möchte aber kein V-Modell unterstellen — auch wenn es danach aussieht. Diese Aktivitäten können Sie auch iterativ und inkrementell durchlaufen. Lesen Sie dazu mehr zur agilen (Software-)Entwicklung

Vorsicht!

Beachten Sie, dass Sie alle Aktivitäten auf der linken Seite mit einer Verifizierung abschließen müssen.

Zusammenspiel von Entwicklungs- und Risikomanagementprozess

Mit einem(!) Prozess die Forderungen der ISO 14971 und ISO 13485 bzw. IEC 62304 erfüllen

Problemstellung

Die meisten für die Entwicklung von Medizinprodukten relevanten Normen wie die ISO 13485, die ISO 14971, die IEC 62304 und die IEC 62366 stellen Anforderungen an Prozesse.

Um diese Anforderungen zu erfüllen, formulieren viele Medizinproduktehersteller Prozessbeschreibungen (SOPs) — und zwar für jeden dieser Prozesse getrennt. Das führt dazu, dass die an der Entwicklung Beteiligten gleichzeitig mehrere dieser SOPs beachten müssen. Fehler sind hier fast vorprogrammiert.

Übersicht

Die folgende Abbildung zeigt zwar ein V-Modell, die Überlegungen sind davon aber unabhängig.

Zusammenspiel von Entwicklungsprozess und Risikomanagementprozess

1. Phase: Kontext und Geschäftsmodell

Der Prozess der Entwicklung eines Medizinprodukts beginnt bereits vor der eigentlichen Entwicklung. Eine der ersten Aufgaben besteht darin, den Geschäftserwartungen und den Kontext zu definieren, in dem das künftige Produkt eingesetzt werden soll (1).

In dieser Phase sollte mit der Zweckbestimmung  das formuliert werden, was die IEC 62366 etwas missverständlich die „Spezifikation der Anwendung“ nennt. Diese präzise und erweiterte Beschreibung der Zweckbestimmung erfüllt gleichzeitig die Forderung der ISO 14971 Kapitel 4.2.

Während dieser ersten Phase sollte der Hersteller die Risikoanalyse im Sinne einer Preliminary Hazard Analysis starten. Bereits aus der Zweckbestimmung wird offensichtlich welche Gefährdungen und Risiken das Produkt verursacht.

Weiterführende Informationen

Lesen Sie hier mehr wie Sie eine Zweckbestimmung gesetzeskonform formulieren.

2. Phase: Stakeholder-Anforderungen

Ebenfalls zu Beginn der Entwicklung, beispielsweise in der zweiten Phase (2), sollte der Hersteller den Risikomanagementplan und damit die Risikopolitik bzw. die Risikoakzeptanzkriterien festlegen und damit den Forderungen der ISO 14971 Kapitel 3 Rechnung tragen.

Weiterführende Informationen

Lesen Sie mehr zum Erheben von Stakeholder-Anforderungen und zum Festlegen der Risikopolitik und der Risikoakzeptanzkriterien.

3. Phase: System-Spezifikation

Die dritte Phase (3) des Entwicklungs- und damit Risikomanagementprozesses ist die Spezifikation des Produkts im Sinne eines Pflichtenheftes. In dieser Phase der Entwicklung beschreibt der Hersteller die Anforderungen an das Produkt aus einer Blackbox-Sicht und damit dessen Inputs und Outputs.

Eine Input und Output-Analyse hilft dabei, weitere Gefährdungen und Risiken zu identifizieren. Mit diesem Teil der Risikoanalyse sollten die Hersteller die Preliminary Hazard Analysis abschließen können und damit die Identifikation und Bewertung der wichtigsten Gefährdungen bzw. Risiken.

Weiterführende Informationen

Lesen Sie hier mehr zum Thema System-Anforderungen und Systemspezifikation.

4. Phase: Systemarchitektur

Die Risikoanalyse kann frühestens abgeschlossen werden, wenn die Entwickler die Anforderungen aus der zweiten Phase in die Planung einer Lösung überführt haben — die Architektur (4). Die Art und Weise, wie das Produkt aufgebaut sein soll, führt zusätzliche Risiken ein oder hilft Risiken zu minimieren. D.h. in Phase (4) sollte die Risikoanalyse in großen Teilen abgeschlossen sein (hier stünde z.B. eine FMEA zur Identifikation weiterer Risiken an).

Gleichzeitig beginnt spätestens in dieser Phase die Planung der Risiko-minimierenden Maßnahmen gemäß ISO 14971 Kapitel 6. Im Risikomanagementprozess ist die Architektur-Phase somit ein Dreh- und Angelpunkt zwischen Risikoanalyse und Risikobeherrschung. Damit soll aber nicht gesagt sein, dass die Architekten die Hauptlast des Risikomanagements tragen sollten.

Weiterführende Informationen

Lesen Sie hier mehr zum Thema System-Architektur und Software-Architektur und zur FMEA.

5. und 6. Phase: Umsetzung und Verifizierung

Die Umsetzung der Architektur und damit der geplanten risikominimierenden Maßnahmen erfolgt in Phase (5), die Verifizierung der Umsetzung und der Wirksamkeit während der Tests (6).

Weiterführende Informationen

Lesen Sie hier mehr zum Thema Software-System-Test.

7. Phase: Validierung

Der Risikomanagementprozess endet zwar nicht mit der Entwicklung bzw. dem Entwicklungsprozess. Aber nach der Validierung bzw. spätestens mit der Freigabe des Produkts (7) muss der Hersteller die abschließende Nutzen-Risiko-Bewertung verfassen, in der er abwägen muss, ob der Nutzen die Gefährdungen bzw. Risiken überwiegt.

Weiterführende Informationen

Lesen Sie hier mehr zur Abgrenzung von Verifizierung und Validierung.

8. Phase: Nachgelagerte Phase, Marktbeobachtung

Wie gerade angedeutet endet weder der Risikomanagementprozess noch die Risikoanalyse mit der Entwicklung. Im Rahmen der nachgelagerten Phase verlangt die ISO 14971 eine kontinuierliche Neu-Bewertung der Risikoakzeptanzkriterien, eine Aktualisierung der Risikoanalyse (z.B. anhand von Marktdaten) und ggf. neue Maßnahmen, um Risiken zu minimieren.

Weiterführende Informationen

Lesen Sie hier mehr zur Post-Market Surveillance.

Fazit

Zusammenfassend empfehlen wir Herstellern, die Aktivitäten, die die ISO 14971 verlangt, in der SOP für den Entwicklungsprozess zu berücksichtigen.

Weiterführende Informationen

Lesen Sie hier mehr zum Risikomanagement nach ISO 14971.


Montag 14. Mai 2018 von Prof. Dr. Christian Johner

Eine effiziente Dokumentenfreigabe stellt eine der wichtigsten Voraussetzungen für ein wirkungsvolles Qualitätsmanagementsystem dar.

Lesen Sie in diesem Artikel, wie Sie die häufigsten Fehler bei der Dokumentenfreigabe vermeiden.

Dokumentenfreigabe: Does & Don’ts | Beitrag lesen »


Mittwoch 23. März 2016 von Prof. Dr. Christian Johner

Der TIR45 („Guidance on the use of AGILE practices in the development of medical device software“) ist ein Technical Information Report (daher TIR) der AAMI, der Association for the Advancement of Medical Instrumentation.

Der 2012 veröffentlichte TIR45 hat sich vor allem ein Ziel gesetzt: Medizinprodukte-Herstellern eine Anleitung zu geben, wie sie Software agil und konform mit den FDA-Forderungen, speziell denen in den Guidance Documents, entwickeln können. Auch die IEC 62304 hat der Technical Report im Fokus.

Lesen Sie hier eine kompakte Zusammenfassung.

TIR45: Agile Software-Entwicklung für Medizinprodukte | Beitrag lesen »


Donnerstag 17. September 2015 von Prof. Dr. Christian Johner

Sie benötigen beides, den (Software-) Entwicklungsplan und die Beschreibung des (Software-) Entwicklungsprozesses, die man häufig auch Entwicklungs-SOP nennt. Doch wie unterscheiden sich die Dokumente? Welche Informationen sollte der Entwicklungsplan enthalten welche die Prozessbeschreibung?

Update: Ergänzung zum Entwicklungsplan
Entwicklungsplan versus Entwicklungsprozessbeschreibung | Beitrag lesen »


Freitag 15. Mai 2015 von Prof. Dr. Christian Johner

Scrum ist eher ein Rahmen (Framework) für das agile Projektmanagement als ein Vorgehensmodell im Sinne eines Prozessmodells. Bereits deshalb kann ein Vorgehen nach Scrum durchaus konform mit den regulatorischen Anforderungen an die Entwicklung von Medizinprodukten (insbesondere Software) und der IEC 62304 sein.

Dieser Beitrag hat nicht zum Ziel, Scrum zu beschreiben (das ist an anderer Stelle z.B. Wikipedia bereits erfolgt). Vielmehr möchte er diskutieren, welche Voraussetzungen erfüllt sein müssen und typische Gefahren vermieden werden sollten.

Scrum (agiles Projektmanagement) am Beispiel der Entwicklung medizinischer Software | Beitrag lesen »


Montag 8. Dezember 2014 von Prof. Dr. Christian Johner

Wir können bei uns nicht automatisiert testen, weil wir sehr Hardware-nah programmieren, antwortet mir mein Kunde auf meine Anregung, durch die Automatisierung gleichzeitig Zeit zu sparen und die Güte der embedded Software zu erhöhen. Und außerdem würde das die IEC 62304 auch nicht verlangen.

Sicher trifft es zu, dass die IEC 62304 keine Automatisierung verlangt. Es ist auch zutreffend, dass bei sehr Hardware-nahe embedded Software die Hardware vorhanden sein muss, um diese Software zu testen. Dennoch: Was eine SW-SOP zum automatisierten Testen bei embedded Software regeln könnte | Beitrag lesen »

Seite 1