Medizinproduktehersteller sind verpflichtet, sowohl den Entwicklungsprozess zu beschreiben als auch einen Entwicklungsplan zu erstellen. Weil beide Dokumente Vorgaben dazu machen, wie Medizinprodukte zu entwickeln sind, gibt es Unsicherheit darüber, welche Information in welches Dokument gehört.
Dieser Artikel löst das auf und betrachtet dabei auch die Software. Er geht ein auf den Software-Entwicklungsplan und die Beschreibung des Software-Entwicklungsprozesses, die man häufig auch „Software-Entwicklungs-SOP“ oder „Verfahrensanweisung Software-Entwicklung“ nennt.
Die Verfahrensanweisung für die Entwicklung (Beschreibung des Entwicklungsprozesses) sollte alle Vorgaben enthalten, die für die Entwicklung aller Produkte gelten.
Hingegen enthält der Entwicklungsplan alle Vorgaben, die spezifisch für die Entwicklung eines speziellen Produkts sind.
Falls der Hersteller nur ein Produkt entwickelt, ist es möglich, beide Dokumente zusammenzulegen. Andernfalls sind weitere Faktoren zu beachten, die dieser Artikel vorstellt.
Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren
1. Beschreibung des Entwicklungsprozesses
Es existieren mehrere weitgehend synonyme Begriffe für „Prozessbeschreibung“. Beim Entwicklungsprozess sind das:
- Beschreibung des Entwicklungsprozesses
- Verfahrensanweisung Entwicklung
- Entwicklungs-SOP
a) Inhalte
Eine Verfahrens- oder Prozessbeschreibung sollte allgemein, d. h. unabhängig von einem konkreten Produkt oder Projekt festlegen, wer wann wie welche Tätigkeit mit welchem Input und welchem Output durchführt.
| Aspekt | Beschreibung | Beispiel |
| Was | Tätigkeiten. die durchgeführt werden müssen | Die Systemarchitektur des Produkts muss entworfen, dokumentiert und verifiziert werden. |
| Wann | Festlegung der sequenziellen oder/und parallelen Reihenfolge der Tätigkeiten. Dazu zählt auch die Festlegung, ob iterativ entwickelt werden kann oder muss. | Direkt nach dem Fertigstellen der Systemarchitektur muss diese verifiziert werden. |
| Wer | Verantwortliche Rollen | Für die Verifizierung der Systemarchitektur ist der Leiter Systems-Engineering verantwortlich. |
| Wie | Methoden und Werkzeuge, mit denen die Tätigkeiten durchgeführt werden sollen | Die Verifizierung muss mithilfe der Checkliste 23B im ALM-Tool durchgeführt und die Ergebnisse dort dokumentiert werden. |
| Inputs | Eingaben für den Prozess bzw. für die Tätigkeiten | Die Eingaben für die Entwicklung sind die Systemanforderungen. Die Eingaben für die die Verifizierung der Architektur sind das Architekturdokument und die Checkliste. |
| Output | Ergebnisse des Prozesses bzw. der Tätigkeiten | Das Ergebnis des Prozesses ist ein vollständig verifiziertes und validiertes Produkt und eine gesetzeskonforme technische Dokumentation. Das Ergebnis der Verifizierung ist eine ausgefüllte Checkliste im ALM-Tool. |
Diese Aspekte erinnern an das Turtle-Diagramm, das als einfaches Modell zum Erstellen von Verfahrens- und Prozessbeschreibungen dient.
Um tiefer in das Thema einzusteigen, bieten sich folgende Informationen an:
b) Entwicklungsprozess: Dokumentation
Die Dokumentation, d. h. die Prozess- oder Verfahrensbeschreibung, enthält üblicherweise:
- Ein Deckblatt mit den Informationen zur Dokumentenlenkung und mit Hinweisen zum Anwendungsbereich
- Eine Prozessübersicht beispielsweise in Form eines Ablaufdiagramms (z. B. UML-Aktivitätsdiagramm)
- Eine Beschreibung der Phasen, welche ein oder mehrere Tätigkeiten gruppieren
- Für jede Phase und/oder Tätigkeit die verantwortlichen Rollen, die erwarteten Inputs, die Methoden, die Werkzeuge und die zu erzeugenden Outputs
Verifizierungsaktivitäten werden dabei mitgeplant.
Beachten Sie, dass der Entwicklungsprozess das Aufstellen eines Entwicklungsplans vorschreiben sollte.
Im Auditgarant finden Sie Templates für einen Entwicklungsprozess und einen Entwicklungsplan.
c) Regulatorische Anforderungen
MDR/IVDR
MDR und IVDR verpflichten die Hersteller, im QM-System vorzuschreiben …
die Produktrealisierung einschließlich Planung, Auslegung, Entwicklung, Herstellung
Artikel 10 MDR, IVDR
Auch in den jeweiligen Anhängen XI fordern die EU-Verordnungen …
Verfahren und Techniken zur Überwachung, Überprüfung, Validierung und Kontrolle der Produktauslegung und die entsprechende Dokumentation sowie die aus diesen Verfahren und Techniken hervorgehenden Daten und Aufzeichnungen.
Anhang IX MDR, IVDR
ISO 13485
Auch die ISO 13485 besteht neben einem Entwicklungsplan (s. u.) auf einer Beschreibung der Prozesse:
Die Organisation muss die Prozesse planen und entwickeln, die für die Produktrealisierung erforderlich sind.
ISO 13485 Kapitel 7.1
Bitte beachten Sie, dass die FDA die Anforderungen der ISO 13485 übernimmt. Damit gelten diese Anforderungen auch für Produkte, die in den USA in den Verkehr gebracht werden sollen.
IEC 60601-1
Die IEC 60601-1 besteht nicht auf einer allgemeinen Beschreibung des Entwicklungsprozesses. Sie fordert für programmierbare elektrische medizinische Systeme (PEMS) „lediglich“:
Es muss ein PEMS-ENTWICKLUNGS-LEBENSZYKLUS dokumentiert werden.
IEC 60601-1 Kapitel 14.4
Diese Forderung lässt sich auch durch einen Entwicklungsplan erfüllen.
IEC 62304
Auch die IEC 62304 besteht auf keiner allgemeinen Prozess- oder Verfahrensbeschreibung. Selbst im Kapitel „Software-Entwicklungsprozess“ fordert sie „nur“ einen Software-Entwicklungsplan und stellt Anforderungen an die Tätigkeiten im Rahmen der Software-Entwicklung.
2. Entwicklungsplan
a) Inhalte
Der Entwicklungsplan muss die Vorgaben für ein konkretes Entwicklungsprojekt bzw. zu entwickelndes Produkt festlegen.
Wenn die „Entwicklungs-SOP“ das Vorgehen weitgehend regelt (also fast alle notwendigen Vorgaben macht), enthält der Entwicklungsplan neben dem Verweis auf die Entwicklungs-SOP nur noch Aspekte wie:
- Konkrete Festlegung der Termine bzw. Zuordnung der Termine zu den im Entwicklungsprozess definierten Meilensteinen
- Zuordnung von Personen zu den Rollen, die die Beschreibung des Entwicklungsprozesses fordert
- Änderungen gegenüber den Vorgaben durch den Entwicklungsprozess (wenn dieser Freiheitsgrade einräumt)
- Sonstige Festlegungen, welche die Prozessbeschreibung erlaubt oder fordert. Beispielsweise kann der Inhalt von Checklisten zum Code Review von der im jeweiligen Entwicklungsprojekt gewählten Programmiersprache abhängen.
b) Dokumentation
Der Entwicklungsplan lässt sich damit auf ein zweiseitiges Dokument eindampfen. Das besteht beispielsweise aus:
- Deckblatt mit
- Referenzen zum Produkt (z. B. UDI-DI)
- Elementen zur Dokumentenlenkung (z. B. Version, Autor)
- Referenz auf den Entwicklungsprozess
- Tabellen mit Zuordnungen, z. B. von Personen zu Rollen
- Kurzen Abschnitten mit Ergänzungen
c) Regulatorische Anforderungen
MDR, IVDR
MDR und IVDR stellen keine spezifischen Anforderungen an Entwicklungspläne.
ISO 13485
Die Qualitätsmanagementnorm besteht auf einem Entwicklungsplan. Welche Inhalte dieser abdecken muss, legt das Kapitel „7.3.2 Entwicklungsplanung“ fest.
Dazu zählen die Entwicklungsphasen. Das bedeutet, dass die Beschreibung des Entwicklungsprozesses (die allgemeine Verfahrensanweisung) diese Vorgaben nicht enthalten muss oder dass der Entwicklungsplan diese Vorgaben überschreiben darf.
IEC 60601-1
Die IEC 60601-1 unterscheidet nicht zwischen der Verfahrensanweisung und dem Entwicklungsplan. Sie verlangt allerdings konkrete Entwicklungsphasen wie die Anforderungsspezifikation und die Architektur.
Orientieren Sie sich am V-Modell als Dokumentationsmodell, um die Anforderungen der IEC 60601-1 zu erfüllen.
IEC 62304
Die IEC 62304 fordert, dass der Entwicklungsplan die im Kapitel „Entwicklungsprozess“ angesprochenen Aspekte adressiert. Dabei ist es üblich, auf den Entwicklungsprozess zu referenzieren. Insbesondere sollte der Software-Entwicklungsplan beinhalten:
- Den konkreten Prozess (Die Norm lässt dabei freie Wahl; der Prozess muss aber festgelegt sein.)
- Die Inputs und Outputs der Tätigkeiten, einschließlich formaler Anforderungen an die Dokumentation
- Das Tracing, das Testing, das Konfigurationsmanagement und die Problemlösung müssen explizit adressiert sein.
- Ziel des konkreten Entwicklungsvorhabens (Verweis auf Software-Anforderungen)
- Werkzeuge
- Normen und/oder eigene Vorgaben wie Kodierrichtlinien
Der Entwicklungsplan soll zuerst vorliegen. Das bedeutet aber, dass Werkzeuge und Vorgaben zum Testen bereits benannt sind. Das ist allerdings nicht immer sinnvoll. Beispielsweise ist es Aufgabe des Software-Architekten, Technologien wie eine Programmiersprache zu wählen, die geeignet sind, die Software-Anforderungen zu erfüllen. Abhängig von der Wahl der Programmiersprache – um das Beispiel fortzuführen – ist jedoch die Wahl
- der Werkzeuge,
- der Testmethoden sowie
- der Art und Weise, wie das Konfigurationsmanagement umgesetzt wird.
Daher ist es oft notwendig, den Entwicklungsplan während des Entwicklungsprozesses anzupassen, was regulatorisch kein Problem ist.
3. Entscheidungskriterien für die Aufteilung zwischen Entwicklungsplan und Entwicklungsprozess
a) Freiheitsgrade
Sie haben die Wahl, ob Sie Ihre Vorgaben eher in der Beschreibung des Entwicklungsprozesses oder eher im Entwicklungsplan dokumentieren (s. Abb. 2).
Im ersten Fall würde der Entwicklungsplan geschrieben, der die Entwicklungs-SOP im Wesentlichen nur referenziert. Im zweiten Fall steht in der Entwicklungs-SOP, dass die Details im Entwicklungsplan festzulegen sind.
b) Entscheidungskriterien
Bei Ihrer Entscheidung, wie Sie die Inhalte auf die beiden Dokumenten aufteilen, können Sie sich von der Art und Größe Ihrer Organisation leiten lassen (s. Tabelle 2).
| Art des Unternehmens | Empfohlene Aufteilung |
| Entwicklungsdienstleister | Sie arbeiten an vielen verschiedenen Projekten und Produkten. Das bedingt verschiedene Technologien und Vorgaben durch die Hersteller. In diesem Fall werden Sie die meisten konkreten Inhalte im Entwicklungsplan dokumentieren. |
| Kleiner Inverkehrbringer mit nur einem Produkt oder wenigen, sehr ähnlichen Produkten | Ihre Vorgehensmodelle bei den einzelnen Produkten unterscheiden sich kaum und Sie können die meisten Inhalte bereits in Ihrer SOP festhalten. |
| Mittlerer bis großer Medizinproduktehersteller | Sie entwickeln viele Produkte mit unterschiedlichen Technologien und Software-Systemen; eine für alle gültige SOP kann nur allgemeingültig bleiben. Die Details regeln die jeweiligen Entwicklungspläne. |
Machen Sie Ihren Entwicklungsprozess auditsicher
Entdecken Sie jetzt, wie Sie Ihren Entwicklungsprozess auditsicher gestalten und dabei weiterhin effizient arbeiten können. Nutzen Sie unseren Auditgarant, um Ihr Medizinprodukt schnell auf den Markt zu bringen und dabei alle relevanten Anforderungen zu berücksichtigen.
4. Fazit und Zusammenfassung
Hersteller haben viele Freiheitsgrade bei der Entscheidung,
- wie sie die Inhalte auf die Verfahrensanweisung zur Entwicklung (Beschreibung des Entwicklungsprozesses) und den Entwicklungsplan aufteilen,
- welche Prozessmodelle sie wählen.
Aber diese Freiheitsgrade dürfen nicht darüber hinwegtäuschen, dass Normen und Gesetze genau regeln, was die Hersteller festzulegen haben. Gleich in welchem Dokument.
Haben Sie Fragen zum Entwicklungsplan oder Entwicklungsprozess? Sind Sie unsicher, ob Ihre Vorgaben den gesetzlichen und normativen Anforderungen genügen? Oder haben Sie das Gefühl, dass Ihre Vorgabedokumente nur bürokratischen „Overhead“ erzeugen?
Melden Sie sich. Wir unterstützen Sie, damit Ihre Audits und Zulassungen sicher und ohne unnötigen Aufwände verlaufen und Ihre Produkte schnell in den Markt kommen.
Änderungshistorie
- 2023-05-20: Artikel komplett überarbeitet. Tabellen eingefügt. Regulatorische Anforderungen den Kapiteln zugeordnet
- 2015-09-17: Erste Version des Artikels
Danke erstmal für den Informativen Beitrag, ist doch schon sehr interessant zu sehen was es da für Unterschiede gibt.
Beste Grüße
Christian