Implementierung und Anwendung eines Software-Entwicklungsprozess nach IEC 62304 – Projekt im Tandem
IPP Praxisbeitrag
Software-Prozess nach IEC 62304 erfolgreich einführen.
Wie ein Medizinproduktehersteller seinen Entwicklungsprozess um IEC 62304-Anforderungen erweitert, Software-Komponenten klassifiziert und den Nachweis für Software-Klasse A und B strukturiert aufgebaut hat.
Die Herausforderung war nicht nur ein neues Dokument. Es ging darum, einen bestehenden Entwicklungsprozess so zu erweitern, dass Softwareentwicklung, Risikomanagement, Nachweise, Rollen und Freigaben logisch zusammenpassen.
Kurzfazit
Was dieses Projekt zeigt.
IEC 62304 wird nicht durch zusätzliche Dokumente erfüllt, sondern durch einen angewendeten Software-Lebenszyklusprozess.
Softwareentwicklung braucht eine eigene Prozesslogik.
Ein bestehender Entwicklungsprozess muss für Software so erweitert werden, dass Planung, Anforderungen, Risiken, Verifikation, Freigabe und Wartung nachvollziehbar geführt werden.
Software-Klasse entsteht nicht aus Bauchgefühl.
Die Klassifizierung muss aus dem Risikomanagement abgeleitet werden. Entscheidend ist der mögliche Schaden vor risikomindernden Maßnahmen.
Vorlagen helfen nur, wenn sie zum Prozess passen.
Dokumente müssen aus der Prozesslogik entstehen. Sonst entsteht eine Dokumentensammlung, aber kein belastbarer IEC 62304-Nachweis.
Ausgangslage
Ein Produkt mit mehreren Software-Komponenten.
Der Kunde ist Hersteller individuell konfigurierbarer Behandlungseinheiten. Da diese Produkte Software enthalten, musste der Entwicklungsprozess die Anforderungen der IEC 62304 abbilden.
Die Behandlungseinheiten bestehen aus mehreren Hauptkomponenten, die jeweils eigene Software enthalten. Dadurch konnte nicht pauschal „die Software“ betrachtet werden. Jede Software-Komponente musste einzeln eingeordnet, klassifiziert und in den Entwicklungs- und Nachweisprozess eingebunden werden.
Genau hier wird IEC 62304 praktisch relevant: Die Norm verlangt nicht nur ein paar zusätzliche Dokumente, sondern einen nachvollziehbaren Software- Lebenszyklusprozess — von Planung und Anforderungen bis Verifikation, Risikobeherrschung, Freigabe und Wartung.
Kernfrage im Projekt: Wie erweitern wir einen bestehenden Entwicklungsprozess so, dass Software nach IEC 62304 sauber geführt, dokumentiert und nachgewiesen werden kann?
Projektziel
Nicht nur Prozess beschreiben. Prozess anwenden.
Ziel war ein IEC 62304-Prozess, der im Unternehmen tatsächlich funktioniert: verständlich, freigegeben, anwendbar und mit belastbaren Nachweisen für die betroffenen Software-Komponenten.
Prozess erweitern
Einführung und Implementierung eines Software-Entwicklungsprozesses nach IEC 62304 als Ergänzung zum bestehenden Entwicklungsprozess.
Prozess anwenden
Anwendung des Prozesses auf die relevanten Software-Komponenten des Medizinprodukts — nicht nur theoretisch, sondern im konkreten Projekt.
Nachweise erstellen
Aufbau vollständiger, nachvollziehbarer IEC 62304-Nachweise für die betroffenen Software-Klassen und Komponenten.
Roter Faden
Dokumente, Verantwortlichkeiten und Freigaben so verbinden, dass der Prozess für alle Beteiligten verständlich und prüfbar bleibt.
Vorgehen
Vom Gap zur anwendbaren Prozesslogik.
IPP startete mit einer strukturierten Gap-Analyse. Daraus entstand kein abstrakter Normvergleich, sondern ein konkreter Erweiterungsplan für den bestehenden Entwicklungsprozess.
Bestehenden Prozess gegen IEC 62304 prüfen
Zuerst wurde geprüft, welche Anforderungen bereits abgedeckt waren und welche softwarespezifischen Prozessschritte ergänzt werden mussten.
Software-Logik in die Entwicklung integrieren
Der bestehende Entwicklungsprozess wurde um IEC 62304-relevante Schritte erweitert. Das Flowchart konnte dadurch optimiert und für Software-Projekte nutzbar gemacht werden.
Dokumente passend zum Prozess aufbauen
IPP erstellte Vorlagen entlang der neuen Prozesslogik. Dadurch entstanden Dokumente nicht isoliert, sondern in der Reihenfolge, in der sie im Prozess benötigt werden.
Software-spezifische Inhalte gemeinsam füllen
Kunde, IPP und externer Software-Entwickler arbeiteten eng zusammen, um die Vorlagen mit belastbaren technischen und regulatorischen Inhalten zu füllen.
IEC 62304 für Klasse A und B dokumentieren
Für die betroffenen Software-Komponenten wurden die erforderlichen Nachweise aufgebaut und der eingeführte Prozess nachvollziehbar angewendet.
Prozess, Vorlagen und Dokumente nutzbar machen
Die erarbeiteten Vorlagen und Dokumente wurden nicht nur erstellt, sondern im Unternehmen abgestimmt und für die weitere Anwendung vorbereitet.
Easy13485 in der Praxis
Schneller werden, weil die Struktur schon da ist.
Ein Grund, warum das Projekt schnell Fahrt aufnehmen konnte, war die vorhandene IPP- und Easy13485-Bibliothek. Statt bei null zu starten, konnte das Projekt auf vorbereitete Prozesslogik, Vorlagen und regulatorisches Erfahrungswissen zurückgreifen.
Genau das ist der praktische Wert von Easy13485: Nicht jedes Projekt muss die Grundstruktur neu erfinden. Prozesse, Rollen, Templates, Nachweise und Freigaben liegen in einer Logik vor, die auf Medizinprodukteprojekte ausgelegt ist.
Prozesslogik statt Dokumentenjagd
Vorlagen entstehen aus dem Prozess heraus. Dadurch wird klar, welches Dokument welchen Zweck erfüllt und wann es benötigt wird.
Projektstart ohne leeres Blatt
Bestehende Easy13485-Strukturen helfen, schneller in die Umsetzung zu kommen — ohne die fachliche Anpassung an das konkrete Produkt zu überspringen.
Ein gemeinsames Verständnis für Nachweise
Kunde, IPP und Software-Entwicklung arbeiten nicht mit getrennten Dokumentenwelten, sondern mit einem gemeinsamen roten Faden.
Ergebnis
IEC 62304 eingeführt, angewendet und nachgewiesen.
Am Ende stand nicht nur ein beschriebener Software-Prozess, sondern ein angewendeter Prozess mit vollständiger Nachweisführung für die relevanten Software-Komponenten.
Fristgerecht abgeschlossen
Das Projekt zur Einführung und Anwendung des Software-Prozesses nach IEC 62304 konnte in kurzer Zeit und fristgerecht abgeschlossen werden.
Software-Klasse A und B abgedeckt
Die neu erstellten Dokumente ermöglichten den vollständigen Nachweis der IEC 62304-Anforderungen für die betroffenen Software-Klassen.
Roter Faden für alle Beteiligten
Prozess, Dokumente und Verantwortlichkeiten waren für Kunde, IPP und externen Software-Entwickler nachvollziehbar verbunden.
Praxisnutzen: Ein gut eingeführter Software-Prozess wirkt über das einzelne Projekt hinaus. Er schafft Klarheit für spätere Entwicklungen, Änderungen, Reviews und weitere Software-Komponenten.
Lesson Learned
Software-Klassifizierung beginnt im Risikomanagement.
Für die Bestimmung der Software-Klasse wurde die Risikoanalyse als zentrales Werkzeug herangezogen.
Entscheidend für die Klassifizierung ist der Schweregrad potenzieller Schäden vor Umsetzung risikomindernder Maßnahmen. Dabei sind die Risiken relevant, die der Maßnahmenkategorie „Software“ zugeordnet sind.
Die Auftretenswahrscheinlichkeit steht dabei nicht im Vordergrund. Entscheidend ist die mögliche Auswirkung auf Patienten, Anwender oder Dritte. Genau deshalb müssen Risikomanagement und Software-Prozess eng verbunden werden.
Merksatz: Wer IEC 62304 sauber anwenden will, darf Software nicht isoliert dokumentieren. Software-Klassifizierung, Risikomanagement, Anforderungen und Nachweise müssen zusammengeführt werden.
Einordnung
Wann ein IEC 62304-Projekt kritisch wird.
Die Einführung eines Software-Prozesses ist besonders kritisch, wenn ein Produkt bereits entwickelt ist, aber Software-Nachweise, Klassifizierung oder Prozesslogik noch nicht sauber zusammenpassen.
Nicht jede Software ist gleich zu behandeln
Wenn ein Medizinprodukt mehrere Software-Komponenten enthält, müssen Scope, Klassifizierung und Nachweisführung je Komponente sauber geklärt werden.
Nachträgliche Prozesslogik ist anspruchsvoll
Wenn Software bereits entwickelt wurde, muss sauber geprüft werden, welche Nachweise vorhanden sind und welche Prozessschritte nachgezogen oder plausibel rekonstruiert werden können.
Software-Lieferanten müssen eingebunden werden
Externe Software-Entwickler liefern zentrale Inhalte. Ohne klare Anforderungen, Verantwortlichkeiten und Nachweislogik entstehen schnell Lücken in der technischen Dokumentation.
Der Prozess muss prüfbar bleiben
Ein IEC 62304-Prozess muss nicht nur intern funktionieren. Er muss auch in Audits, Reviews und technischer Dokumentation nachvollziehbar erklärt werden können.
Weitere interessante Artikel
Mehr Orientierung für Software, MDR und technische Dokumentation.
Diese Beiträge zeigen, wie IEC 62304, technische Dokumentation, MDR-Konformität, Easy13485 und Auditfähigkeit in der Praxis zusammenhängen.
Easy13485
QMS, Rollen, Prozesse, Nachweise und Freigaben als strukturierter Rahmen für Medizinprodukteprojekte.
Umstellung Klasse IIa TecDoc auf MDR
Praxisbeispiel für die erfolgreiche Überführung technischer Dokumentation in eine MDR-fähige Einreichungslogik.
CE-Konformität nach MDR
Einordnung, wie technische Dokumentation, Nachweise, Konformitätsbewertung und regulatorische Entscheidungen zusammenwirken.
Technische Dokumentation nach MDR für extraorale Röntgengeräte
Beispiel für produktbezogene Nachweisführung, technische Dokumentation und MDR-Reviewfähigkeit.
Notfallmaßnahmen für MDR Audit Abweichungen
Was passiert, wenn technische Dokumentation, Prozesse oder Nachweise im Audit nicht tragen — und wie man schnell wieder handlungsfähig wird.
Ähnliches Projekt?
Software-Prozess, Klassifizierung oder Nachweise klären.
Wenn Software in Deinem Medizinprodukt eine Rolle spielt, lohnt sich eine frühe Klärung: Welche IEC 62304-Anforderungen gelten, welche Software-Klasse ist plausibel und welche Nachweise fehlen noch?
IPP unterstützt bei Software-Prozessen, Risikomanagement, Requirements, technischer Dokumentation und Projektsteuerung — punktuell oder als Teil eines größeren MedTech-Projekts.
Projekte wie diese zeigen, wie wichtig ein klar strukturierter Software-Entwicklungsprozess nach IEC 62304 für den Marktzugang ist – und wie effektiv unser Easy13485 Framework Startups und Herstellern hilft, diesen effizient umzusetzen. Besonders stolz macht mich die enge, vertrauensvolle Zusammenarbeit mit unserem Kunden, bei der aus anfänglicher Komplexität eine nachvollziehbare, auditfähige Dokumentation wurde. Gemeinsam schneller zum Ziel – genau dafür steht IPP.