Medical SPICE® in der Praxis: Assessments, Prozessreife und Softwarequalität
Was Medical SPICE® jetzt entscheidend macht
Torsten Hertz (er-)lebt seit über 30 Jahren die Medizintechnik entlang des gesamten Produktlebenszyklus. Seit 2018 betreut er als qtec Experte internationale Kunden aus der Health-Branche zu allen Aspekten des Systems Engineerings, des Anforderungsmanagements, der Produktsicherheit, der Verifizierung & Validierung sowie des Software Qualitätsmanagements.
Durch seine Erfahrung als Entwickler, Projekt- und Entwicklungsleiter für aktive Medizingeräte und Health Apps weiß er, worauf Kunden bei der erfolgreichen Entwicklung von Produkten besonders achten sollten - um somit das Fehlerrisiko in den Prozessen und dem Design von Anfang an zu minimieren und die Einhaltung von regulatorischen Vorgaben zu sichern.
Als Berater weiß er, dass durch eine systematische Vorgehensweise und der dabei angewandten qtec-Methodik die Komplexität von Produkten und Systemen beherrschbar wird - sowohl bei Neuentwicklungen als auch bei Bestandsprodukten. Durch interaktive Teilnahme in Fachgesellschaften, z.B. im VDI-Fachausschuss "Software in der Medizintechnik" oder im INCOSE(1) / GfSE(2) bleibt er kontinuierlich auf dem Stand der Technik und der anwendbaren regulatorischen Prozesse.
Bei qtec ist er verantwortlich für das modellbasierte Systems Engineering. In dieser Domäne präsentiert er als Speaker auf Konferenzen wie zum Beispiel der MedConf und dem TdSE(3) unterschiedliche Fachthemen aus der Medizintechnik-Domäne. Als Trainer schult Torsten Hertz bei der qtec Academy eine Vielzahl von Themen wie der Systemanalyse und -modellierung, Simulation, Requirements-Engineering, Produkt- und Software-Lebenszyklen, Agile Entwicklung uvm.
- Deswegen lohnt sich ein Blick
- Das ist Medical SPICE®
- Adressierte Herausforderungen in der Entwicklung
- Reduzierung von Redundanzen
- Unterschied zu klassischen normativen Anforderungen
- Warum wurden IEC 82304-1 und IEC 81001-5-1 aufgenommen?
- Schaffung von Struktur und Transparenz
- Diese Rolle spielen Prozessreife und Capability Levels
- Bedeutung: Prozess Reifegrad Level 1
- Typische Schwächen bei Assessments oder internen Audits
- Bedeutung von Basispraktiken und Arbeitsprodukten
- Verknüpfung von Prozessen, Nachweisen und Dokumentation
- Welche Rolle spielen Software-Problemlösungsprozesse SPR?
- Herausforderungen beim Management von Softwareänderungen in regulierten Produkten
- Softwarequalität langfristig und nachhaltig verbessern
- Wer sollte sich mit Medical SPICE® bschäftigen?
- zentralen Rat für die Einführung oder Nutzung von Medical SPICE®
Frage
Antwort
Die aktuelle Ausgabe der VDI 5702-Blatt 1 berücksichtigt nun die seit 2017 (Veröffentlichung der ersten Ausgabe) bis praktisch heute erschienenen neuen Norm-Versionen im Kontext des Medizinprodukte-Lebenszyklus.
Man muss sich vor Augen halten, dass 2017 noch die Vorgaben einer MDD (Medical Device Directive) verbindlich waren. Die gegenwärtig verpflichtende MDR (Medical Device Regulation) zog seitdem eine Reihe von aktualisierten Normen nach sich, um den gestiegenen regulatorischen Anforderungen der MDR - z.B. über die ISO 13485:2016 und die im EU-Bereich harmonisierten, anwendbaren Normen - gerecht zu werden.
Sowohl Hersteller als auch Benannte Stellen investieren einen hohen Aufwand, um diese anspruchsvollen normativen Anforderungen einzuhalten, respektive zu prüfen – daher ist es allemal lohnend, sich mit dem in Medical SPICE® vorgestellten Vorgehens- und Bewertungsmodell zu beschäftigen.
Frage
Antwort
Medical SPICE® ist die Übertragung des generischen, reifegradbasierten Prozessmodells SPICE (Software Process Improvement and Capability Determination) auf die anwendbaren Basisnormen der Medizintechnik – und zwar im Kontext des Software-Lebenszyklus.
Erstaunlicherweise gab es in der Medizintechnik - als Beispiel für eine recht hochregulierte Branche - bislang kein solches Reifegradsystem nach ISO/IEC 33001. In der Automotive-Branche etwa wird seit vielen Jahren Automotive SPICE® (ASPICE) angewendet, welches SPICE für den Lebenszyklus von sicherheitskritischer Software - eingebettet in Fahrzeuge - implementiert.
In der MedTech treten in den letzten Jahren sehr viele Aspekte, wie z.B. Vernetzung, Cyber-Security, Datenmanagement, Zuverlässigkeit, Funktionale Sicherheit und Usability mehr und mehr in den Vordergrund – und stehen damit fast auf der gleichen Ebene wie die Hauptfunktionen der Therapie, der Überwachung und der Diagnostik.
Kommt dir bekannt vor?
Dann lass uns drüber sprechen. Unsere Expertinnen und Experten kennen genau diese Herausforderungen – und unterstützen MP-Hersteller flexibel, pragmatisch und auf Augenhöhe.
Frage
Antwort
Hierzu ein Beispiel aus der Praxis: Du planst als Hersteller eines aktiven Medizinprodukts die Entwicklung der eingebetteten Software als externes Gewerk zu beauftragen. Bei der Auswahl möglicher Dienstleister benötigst Du objektiv bewertbare Kriterien – und genau diese liefert Medical SPICE® - angewandt auf referenzierbare Prozesse, Basispraktiken und Arbeitsprodukte.
Als ein Assessor für Medical SPICE® bist Du damit in der Lage, die Prozessreife der Dienstleister zu vergleichen und damit eine Entscheidung für einen Anbietenden zu treffen.
Aber auch für den Fall, dass Du die Software intern entwickeln und pflegen möchtest, lässt sich durch Anwendung des Schemas in Medical SPICE® der Reifegrad der Prozesse in einem internen Audit bestimmen und kontinuierlich verbessern.
Frage
Antwort
Die zentralen Normen, welche verbindlich sind für Medizinprodukte mit eingebetteter oder alleinstehender Software:
- IEC 60601-1 (Allgemeine Festlegungen für die Sicherheit)
- IEC 62304 (Software-Lebenszyklus-Prozesse)
- IEC 82304-1 (Allgemeine Anforderungen für die Produktsicherheit)
- IEC 62366-1 (Anwendung der Gebrauchstauglichkeit auf Medizinprodukte)
- ISO 14971 (Anwendung des Risikomanagements auf Medizinprodukte)
- IEC 81001-5-1 (Security - Aktivitäten im Produktlebenszyklus)
referenzieren an mehreren Stellen inhaltlich überlappende Klauseln. Würde man die Normen isoliert voneinander betrachten, so würden sehr ähnliche Prozessschritte mehrfach ausgeführt, die sehr wahrscheinlich sehr ähnliche Arbeitsprodukte erzeugen bzw. referenzieren. Diese ungewollte Redundanz birgt die Gefahr von Inkonsistenzen, erzeugt vermeidbare Aufwände der Erstellung und Pflege und bläht die Produkthauptakte unnötig auf.
Von einer minimalen Redundanz profitieren damit sowohl Hersteller als auch Benannte Stellen, was nach einer Einreichung die Dauer bis zu einer Zulassung verkürzen kann.
Beispiel: Eine Planung und Dokumentation des Risikomanagements werden in praktisch allen genannten Normen eingefordert.
Frage
Antwort
Ein weiteres Grundprinzip von Medical SPICE® ist, dass keine normativen Klauseln „zuerfunden“ werden, aber auch nichts weggelassen wird. Hierzu ist es hilfreich zu verstehen, wie diese Richtlinie entstanden ist: Alle genannten Normen wurden in ihre jeweiligen Klauseln semantisch zerlegt und dabei Redundanzen entfernt. Dann wurden die verbleibenden Klauseln als Basispraktiken mit Arbeitsprodukten formuliert, Prozessen zugeordnet und in Prozessgruppen sortiert, die den Lebenszyklus der Software widerspiegeln.
Somit kann man nicht direkt von Unterschieden zu den klassischen Normen sprechen; Medical SPICE® lässt sich eher als redundanzfreie „Compilation“ aus den einzelnen Normen bezeichnen. Jedes Element der Richtlinie referenziert (im Anhang C) mindestens eine Klausel der ursprünglichen Norm (bezeichnet als „Mapping“).
Frage
Antwort
Diese beiden neu aufgenommenen Normen zeichnen ganz gut das Bild der mittlerweile deutlich gestiegenen regulatorischen Anforderungen.
Die IEC 81001-5-1 bringt den Aspekt der Cyber-Security mit. Dies war im Zuge der rasch zunehmenden Vernetzung von Medizinprodukten notwendig, um eine angemessene Produktsicherheit und Produktintegrität auf systemischer Ebene einzufordern.
Die IEC 82304-1 verallgemeinert und ergänzt viele Aspekte der seit vielen Jahren etablierten IEC 62304. So wird nun der Lebenszyklus um die Software-Validierung erweitert; der Gültigkeitsbereich liegt klar auf „Health Software“ allgemein - umfasst also auch Software als ein Medizinprodukt und ist anwendbar auf z.B. digitale Gesundheitsanwendungen.
Frage
Antwort
Frage
Antwort
Frage
Antwort
In Level 1 der Reifegraddimension wird geprüft, ob die Prozessdurchführung überwiegend (50% ... 85%) oder besser vollständig (86% … 100%) erfolgt ist – also der umgesetzte Prozess seinen Prozesszweck erfüllt.
Die Level 2 ... 5 bewerten auf einer generischen Ebene wie die Prozesse per se als gesteuert, etabliert, vorhersagbar und optimierend eingestuft werden können.
Der Level 0 sagt aus, dass der Prozess nicht zielführend ausgeführt wird bzw. jegliche Nachweise zu dessen Ausführung fehlen.
Frage
Antwort
Beim Assessment gemäß Medical SPICE® untersucht man ausgehend von den Arbeitsprodukten (in der Regel sind dies die Dokumente) die Prozesse und deren Erfüllung. Die häufigsten Schwachpunkte (und mögliche Gegenmaßnahmen) sind:
- lückenhafte Prozesse > Lücken füllen
- überladene Prozesse > auf mehrere Prozesse aufteilen
- fehlende Nachweise > Aufzeichnungen erzeugen und (auffindbar) ablegen.
- Schlechtes Versionsmanagement > Etablierung eines passenden Werkzeugs
Frage
Antwort
Dies sind die elementaren Bausteine, die den kompletten Software-Lebenszyklus abbilden. Modelltechnisch sind die Basispraktiken im Sinne der Richtlinie die Prozess-Aktivitäten; die Arbeitsprodukte sind die Dokumente bzw. Artefakte welche die Produkthauptakte „befüllen“.
Übrigens: In der aktuellen Version der VDI 5702-Blatt 1:2026 gibt es 174 Basispraktiken, aufgeteilt in 24 Prozesse und zusammengefasst in fünf Prozessgruppen – sowie 80 Arbeitsprodukte!
Frage
Antwort
Frage
Antwort
In der Prozessgruppe SPR geht es um:
- die Erfassung, Bewertung und Kommunikation von Problemen und Anomalien
- die Erstellung von Änderungsanträgen
- das Freigeben und die Umsetzung von Änderungsanträgen
- die Dokumentation und die Verifizierung der Lösung
Dies sind die zentralen Aktivitäten, die den Software-Lebenszyklus nach der Entwicklungsphase fortsetzen, im Sinne der Wartung / Pflege und neuen Features / Leistungsmerkmalen.
Frage
Antwort
Diese Herausforderungen ergeben sich unmittelbar, sobald die eben genannten Aktivitäten unzureichend umgesetzt sind – und beim Audit zu Abweichungen bzw. Ablehnungen führen:
- Keine vereinheitlichte und verfolgbare Erfassung von Problemen
- Schlecht gelenkte Änderungsanträge
- Intransparente Kriterien bei der Entscheidung über die Änderung
- Unzureichende verifizierende Maßnahmen, Fehlen von Regressionstests nach der Änderung
Frage
Antwort
Wie in den vorangegangenen Antworten beschrieben, hilft Medical SPICE® in allen Phasen des Software-Lebenszyklus die Qualität der Medizinprodukt-Produkte zu sichern und zu verbessern. Die aktuelle Richtlinie VDI 5702-Blatt 1 von 2026 stellt ein Vorgehensmodell und Bewertungsmodell bereit:
- Ein Prozess Assessment Modell (PAM) als Agenda zur Lieferantenbewertung oder zu internen Audits im Kontext der Health Software Entwicklung
- Ein Prozess Referenz Modell (PRM) mit welchem sich eine eigene Prozesslandschaft „bauen“ lässt.
Fairerweise muss man sagen, dass VDI 5702-Blatt 1 Dir nicht vorschreibt, wie (es gemacht) sondern spezifiziert, was (gebraucht wird) – damit Du Software für Medizinprodukte erfolgreich entwickeln und nachhaltig pflegen kannst.
Möchtest Du allerdings bei der Implementierung eines Prozessmodells von langjährigen Erfahrungen / Best Practices profitieren, dann ist die VDI-Expertenempfehlung VDI-EE 5702 Blatt 3 (Medical SPICE® - Empfehlungen für die Softwareentwicklung) eine gute Ergänzung und Inspiration für den Weg, der vor Dir liegt.
Oder wende Dich bei Bedarf an professioneller Unterstützung einfach an qtec – wir können Dir bestimmt helfen!
Frage
Antwort
Alle Teams und Rollen, die unmittelbar im Lebenszykluspfad der Medizin-Software involviert sind, insbesondere SW-Qualitätssichernde. Aber auch Prozessmanager, Riskmanager, Projektmanager und Regulatory Affairs-Expert:innen.
Falls Du Dich selbst zu einer Assessor:in für Medical SPICE® weiterbilden bzw. zertifizieren lassen möchtest, dann wirf ruhig einen Blick in die Richtlinie VDI-MT 5702 Blatt 2 (Medical SPICE® Qualifizierung von Entwickelnden und Assessoren).
Frage
Antwort
Falls Du ein Hersteller von Medizinprodukten bist, welche Software enthalten – oder Software, die ein Medizinprodukt sind: Nutze das PAM aus VDI 5702 Blatt 1 um externe Dienstleister aus der SW-Domäne erfolgreich im Rahmen einer Lieferantenbewertung zu evaluieren.
Falls Du ein Dienstleister aus der SW-Domäne bist: Bereite Deine SWQA-Prozesslandschaft rechtzeitig auf Assessments gemäß Medical SPICE® VDI 5702 Blatt 1 vor – der nächste potenzielle Auftraggeber aus der MedTech-Branche könnte bereits vor der Tür stehen!
In jedem Fall kannst Du im frei zugänglichen Blog-Artikel Health-Software: Medical SPICE® (VDI 5702-Blatt 1:2026) von qtec - anhand von Illustrationen und Beispielen - noch weiter in die spannende Welt von Medical SPICE® eintauchen - Viel Spaß dabei!
Unser Newsletter „qonzentrat“
kompakt, professionell und präzise
Profitiere von unserem Fachwissen.
Jetzt anmelden
