Health-Software: Medical SPICE® (VDI 5702-Blatt 1:2026)
So prüfst und managst du erfolgreich Software-Lebenszyklen mithilfe des Assessment-Modells Medical SPICE®
Erfahre in diesem Artikel wie du das reifegradbasierte Prozessmodell Medical SPICE® für deine Health-Software-Projekte und -Lebenszyklen sinnvoll nutzen kannst. Die Neuauflage der Technischen Regel VDI 5702-Blatt 1 aktualisiert seit Januar 2026 einige Aspekte im Vergleich zur Erstausgabe aus dem Jahr 2017. Es lohnt sich also, in diese Richtlinie etwas genauer hineinzuschauen.
- Einleitung
- Normativer Kontext
- Was ist SPICE?
- SPICE in unterschiedlichen Fach- und Wissensgebieten
- Prozessgruppen, Basispraktiken und Arbeitsprodukte in Medical SPICE®
- Insights: Die Software-Problemlösungsprozesse – SPR
- Zusammenfassung
- Ausblick
- Glossar der wichtigsten Begriffe zu Medical SPICE® (DE,EN)
Einleitung
Der hohe Stellenwert von qualitativ hochwertiger Software in der Medizintechnik kann gar nicht oft genug hervorgehoben werden. Entlang des gesamten Lebenszyklus von softwarebasierten Medizinprodukten greifen eine Reihe von Prozessen ineinander, welche wiederum eine Vielzahl von Dokumenten und Aufzeichnungen hervorbringen.
Die anwendbaren, harmonisierten Normen (siehe Abschnitt Normativer Kontext) referenzieren sich untereinander, erzeugen aber leider auch Redundanzen im Vorgehen und den Dokumenten.
Ein bedeutender Anspruch der Richtlinie VDI 5702-Blatt 1 Medical SPICE® ist daher, diese Redundanzen zu identifizieren und zu beseitigen, was die Aufwände bei der Durchführung der Prozesse und der Dokumentenerstellung signifikant verringert – und somit auch das SPOT-Prinzip (Single Point of Truth) erfüllt, siehe Abschnitt Normativer Kontext.
Ein weiteres Grundelement der VDI 5702-Blatt 1 ist die Anwendung eines Prozessbewertungsmodells ([EN] Process Assessment Model, PAM), siehe Abschnitt Was ist SPICE?. Dieses PAM eignet sich bestens als Bewertungsschema für z.B. Lieferanten-Audits von Dienstleistern / Auftragnehmer - aber auch für interne Audits.
Ein dritter und wesentlicher Benefit der Richtlinie ist die Übertragbarkeit des PAMs auf ein Prozessreferenzmodell ([EN] Process Reference Model, PRM), mit dem man in die Lage versetzt wird, ein eigenes und normkonformes Prozessmodell bestehend aus elementaren Basispraktiken und Arbeitsprodukten zu definieren, siehe Abschnitt Prozessgruppen, Basispraktiken und Arbeitsprodukte in Medical SPICE®.
Normativer Kontext
Wie weiter oben beschrieben vermeidet Medical SPICE® die redundante Ausführung gleicher oder ähnlicher Prozessschritte, die übergreifend in diesen Normen eingefordert werden. Für die neu erschienene zweite Ausgabe der VDI 5702-Blatt 1 [1] sind dies:
Die aktualisierten Ausgaben der referenzierten Normen gegenüber 2017:
- IEC 60601-1:2020-08 (Ed. 3.2) [4]
Medizinische elektrische Geräte - Teil 1: Allgemeine Festlegungen für die Sicherheit einschließlich der wesentlichen Leistungsmerkmale - IEC 62304:2015-06 (Ed. 1.1) [5]
Medizingeräte-Software - Software-Lebenszyklus-Prozesse - IEC 62366-1:2020-06 (Ed. 1.1) [6]
Medizinprodukte - Teil 1: Anwendung der Gebrauchstauglichkeit auf Medizinprodukte - ISO 14971:2019-12 [7]
Medizinprodukte - Anwendung des Risikomanagements auf Medizinprodukte
Neu hinzugekommen gegenüber der Ausgabe aus dem Jahr 2017 sind die folgenden Normen:
- IEC 82304-1:2016-10 [8]
Gesundheitssoftware - Teil 1: Allgemeine Anforderungen für die Produktsicherheit - IEC 81001-5-1:2021-12 [9]
Anwendung des Risikomanagements für IT-Netzwerke, die Medizinprodukte beinhalten - Sicherheit, Effektivität und Daten- und Systemsicherheit bei Implementierung und Gebrauch von eingebundenen Medizinprodukten oder eingebundener Gesundheitssoftware - Teil 5-1: Aktivitäten im Produktlebenszyklus
Im Anhang der Richtlinie wird ausführlich auf das Mapping der Anforderungen seitens Medical SPICE® auf die obigen Standards eingegangen.
Es ist wichtig zu erwähnen, dass die VDI 5702-Blatt 1 keine neuen normativen Anforderungen „hinzudichtet“; sie bildet also eine redundanzfreie und strukturierte Zusammenstellung aller Klauseln der oben aufgeführten Normen.
Die Richtlinie ist zweisprachig in DE und EN verfasst.
Zeitdruck, Ressourcenmangel oder steigende regulatorische Anforderungen?
Wir stellen dir passgenaue Fachleute für deine Medizinprodukte-Projekte zur Seite, schnell, qualifiziert und projekterfahren.
Was ist SPICE?
Seit Ende der 1990er Jahre etablieren sich reifegradbasierte Prozess-Frameworks wie SPICE (1998) und CMMI (2002) in der Industrie. Ziel ist einerseits die kontinuierliche Verbesserung von Software-Entwicklungsprozessen, andererseits aber auch die Bestimmung der Prozessfähigkeit ([EN] Capability Determination) in einer bestehenden Prozesslandschaft.
Das Akronym SPICE steht für „Software Process Improvement and Capability Determination“; die
zugehörige Norm ISO/IEC 15504-1 wurde inzwischen durch ISO/IEC 33001 - sowie ISO/IEC 15504-2 durch ISO/IEC 33002 [10] (und weitere Normen in diesem Nummernkreis) - abgelöst.
In der Regel werden zusammengehörige Software-Prozesse (entlang des SW-Lebenszyklus) eindeutig benannt und in Prozessgruppen thematisch zusammengefasst. Die Bewertung erfolgt nach einem zweidimensionalen Schema: Zum einen gibt es die Prozessdimension ([EN] Process Dimension, PD), entlang deren Achse alle beteiligten und zu bewertenden Prozesse angeordnet sind; und zum anderen die Achse der Befähigungsdimension ([EN] Capability Dimension, CD)
Prozessbefähigung, Reifegradstufen und Prozessattribute
Für jeden Prozess entlang der PD-Achse wird die Befähigung anhand der jeweiligen Prozessattribute ([EN] Process Attribute, PA) ermittelt und somit eine Einteilung in Reifegradstufen ([EN] Level) entlang der CD-Achse erreicht:
Jeder dieser Level fordert unterschiedlich zu bewertende Prozessattribute ein – mit Ausnahme des Level 0, welcher als unvollständiger Prozess keine oder kaum vorhandene Belege als Nachweis einer Prozessbefähigung zu bieten hat.
Level 1 zeigt als Ergebnis der Bewertung des Prozessattributs PA 1.1 an, in welchem Maße jeder einzelne (Teil-)Prozess ausgeführt und nachgewiesen wird. Dies ist das Kernstück von SPICE. Spezifisch für das jeweilige Fachgebiet werden hierzu Basispraktiken (als Prozessschritt, [EN] Base Practice, BP) und Arbeitsprodukte (als Nachweise, [EN] Working Products, WP) bewertet und zur Bestimmung der Prozessbefähigung herangezogen.
Vereinheitlichte Bewertungsskala
Dabei kommt die folgende, vereinheitlichte Bewertungsskala nach ISO/IEC 33001 zur Anwendung. Jedes betrachtete Prozessattribut lässt sich anhand von Indikatoren per Erfüllungsgrad {F,L,P,N} bewerten.
| Symbol | Bedeutung | Quantitativ | Beschreibung |
|---|---|---|---|
| F | Vollständig erfüllt ([EN] Fulfilled) |
>85% … 100% | Es gibt Anzeichen für eine vollständige und systematische Vorgehensweise und eine volle Erfüllung des definierten Prozessattributs im dem bewerteten Prozess. Im bewerteten Prozess gibt es keine signifikanten Schwächen bezüglich des Prozessattributs. |
| L | Überwiegend erfüllt ([EN] Largely fulfilled) |
>50% … 85% | Es gibt Anzeichen für eine systematische Vorgehensweise und eine signifikante Erfüllung des definierten Prozessattributs in dem bewerteten Prozess. Im bewerteten Prozess können einige Schwächen bezüglich des Prozessattributs existieren. |
| P | Teilweise erfüllt ([EN] Partially fulfilled) |
>15% … 50% | Es gibt einige Anzeichen für eine Vorgehensweise und eine teilweise Erfüllung des definierten Prozessattributs in dem bewerteten Prozess. Einige Aspekte der Erfüllung des Prozessattributs können unvorhersagbar sein. |
| N | Nicht erfüllt ([EN] Not fulfilled) |
0% … 15% | Es gibt keine oder geringe Anzeichen der Erfüllung des definierten Prozessattributs bei dem bewerteten Prozess. |
Für das Ziel der Erreichung des Reifegrads Level 1 wird wie schon beschrieben das Prozessattribut PA 1.1 herangezogen. Dazu müssen die Anforderungen für jede Basispraktik zu mehr als 50% erfüllt sein, also per Erfüllungsgrad F oder L bewertet sein.
In diesem Artikel werden wir uns auf Level 1 beschränken, da genau hier alle Basispraktiken und Arbeitsprodukte für den Lebenszyklus von Medizinprodukte-Software referenziert werden.
Höhere Reifegradstufen
Die Level 2…5 (mit weiteren Prozessattributen) zeigen hingegen an, wie konsequent die bewertete Organisation die in Level 1 definierten und ausgeführten Prozesse über den gesamten Lebenszyklus einhält, beobachtet und verbessert.
SPICE in unterschiedlichen Fach- und Wissensgebieten
Im nächsten Kapitel wird auf die Spezialisierung des generischen SPICE-Frameworks - angewandt auf das Fachgebiet der Medizingeräte-Software - eingegangen: Medical SPICE®.
Es gibt allerdings auch weitere Domänen-Spezialisierungen, hier nur eine Auswahl:
- Automotive SPICE (ASPICE)
Die Norm ISO 26262 (Funktionale Sicherheit von Kraftfahrzeugen, [EN] Road vehicles – Functional safety) beschreibt ein Vorgehensmodell, das auf dem SPICE-Framework basiert. - Hardware SPICE
SPICE angewendet auf Entwicklung (elektrischer/elektronischer) Hardware. - Mechanical SPICE
SPICE angewendet auf Entwicklung mechanischer Elemente. - TestSPICE
Der Anwendungsbereich von TestSPICE deckt Tests von Software & Systemen sowie zugehörige Test-Aktivitäten ab. - Modeling & Simulation SPICE
SPICE angewendet auf die Bewertung der Prozessfähigkeit bei der Entwicklung von glaubwürdigen Simulationsmodellen.
Das Assessor-Zertifizierungsportal iNTACS [13] gibt eine gute Übersicht zu SPICE und weitere hilfreiche Informationen.
Prozessgruppen, Basispraktiken und Arbeitsprodukte in Medical SPICE®
Der Lebenszyklus von Software in der Medizintechnik wird bei Medical SPICE® in Prozesse gegliedert, die wiederum in Prozessgruppen zusammengefasst sind.
Übersicht der Prozessgruppen in Medical SPICE®
Die Prozessgruppe SD
- unterteilt sich in Prozesse zur Entwicklung von Software als Bestandteil von Medizinprodukten, in Hinsicht auf Planung, Anforderungen, Architektur, Design, Implementierung, Verifizierung, Freigabe sowie Risikomanagement.
- Um ein besseres Gefühl für den gewachsenen Umfang der neuen Ausgabe der VDI 5701-Blatt1 im Vergleich zur ersten Ausgabe von 2017 zu bekommen, stellen wir hier auch ein paar Kennzahlen vor: Die Prozessgruppe SD referenziert 10 Prozesse mit in Summe
- 66 Basispraktiken in der ersten Auflage von VDI 5702-Blatt 1
- 84 Basispraktiken in der zweiten Auflage von VDI 5702-Blatt 1
Die Prozessgruppe SDD
- erweitert die Prozessgruppe SD um Prozesse, die zusätzlich für die Entwicklung von Standalone-Software (Software as a Medical Device, SaMD) benötigt werden. Insbesondere kommt hier die Software-Validierung hinzu.
- Diese referenziert 7 Prozesse mit in Summe
- 41 Basispraktiken in der ersten Auflage von VDI 5702-Blatt 1
- 46 Basispraktiken in der zweiten Auflage von VDI 5702-Blatt 1
Die Prozessgruppe SM
- umfasst Prozesse, die den Lebenszyklus nach der ersten Freigabe der Software bestimmen, also typischerweise die Phasen der Wartung und Weiterentwicklung.
- Diese referenziert 3 Prozesse mit in Summe
- 15 Basispraktiken in der ersten Auflage von VDI 5702-Blatt 1
- 19 Basispraktiken in der zweiten Auflage von VDI 5702-Blatt 1
Die Prozessgruppe SCM
- stellt Prozesse zum Konfigurationsmanagement der Software bereit, die zur Unterstützung in den Phasen Entwicklung und Wartung benötigt werden.
- Diese referenziert 2 Prozesse mit in Summe 12 Basispraktiken.
Die Prozessgruppe SPR
- beinhaltet Prozesse zur Software-Problemlösung, die ebenfalls die Aktivitäten in den Phasen Entwicklung und Wartung unterstützen.
- Diese referenziert 2 Prozesse mit in Summe 13 Basispraktiken.
Damit definieren die fünf Prozessgruppen insgesamt:
- 147 Basispraktiken mit insgesamt 70 Arbeitsprodukten in der ersten Auflage von VDI 5702-Blatt 1
- 174 Basispraktiken mit insgesamt 80 Arbeitsprodukten in der zweiten Auflage von VDI 5702-Blatt 1
Übersicht der Arbeitsprodukte (Auszug)
Die Arbeitsprodukte sind ausleitbare Artefakte, die (auch) in dem (e)DHF abgelegt werden, zum Beispiel:
- Pläne wie [B1.02] Software development plan,
- Listen wie [B1.28] Known anomaly list,
- Spezifikationen wie [B1.13] Software requirements,
- Reports, wie [B1.53] Risk management report,
- Aufzeichnungen wie [B1.40] Software build record
- aber auch ausgelagerte Prozesse bzw. Aktivitäten wie [B1.51] Risk management process.
Insights: Die Software-Problemlösungsprozesse - SPR
Schauen wir uns die Prozessgruppe Software-Problemlösungsprozesse SPR genauer an. Diese besteht aus zwei Prozessen; zum einen dem (Kern-)Prozess der Problemlösung SPR.1 und zum anderen dem (unterstützenden) Prozess des Managements von Softwareänderungen SPR.2. Die Abbildung 2 stellt diesen Zusammenhang dar.
Prozess der Problemlösung - SPR.1
Dieser Prozess behandelt die Analyse des vorliegenden SW-Problems. Der Begriff „Problem“ umfasst dabei jegliche Anomalien und Abweichungen, die im gesamten Software-Lebenszyklus – also auch während der Entwicklungsphase – festgestellt werden.
Die Abbildung 3 zeigt die sieben Basispraktiken SPR.1_BP.1…7 (hier jeweils modelliert als Aktivität ([EN] Activity)), die im Kontext des Prozesses der Software Problemlösung SPR.1 in der Abfolge der Nummerierung ausgeführt werden sollen. Sechs dieser Basispraktiken erzeugen (in diesem Falle) vier Arbeitsprodukte.
Die Zusammenhänge lassen sich unmittelbar aus der abgebildeten Sicht herauslesen. Beispiel: Die Basispraktik für die Erstellung der Änderungsanforderung ([SPR.1_BP.6] „Create change request“) erzeugt
- die Aufzeichnung der Problemuntersuchung [B1.59] „Problem investigation record“ sowie
- die Änderungsanforderung [B1.55] „Change request“.
Der Prozess gilt als erfüllt, sobald die eingeforderten sieben Ergebnisse ([EN] Outcomes) nachgewiesen werden können.
Der Begriff des „Ergebnisses“ vereint das Vorliegen der assoziierten Dokumente mit der Ausführung der zugehörigen Basispraktiken; es geht also um erreichte Zustände und nachweisbare Kriterien – sozusagen um das „Definition of Done“.
Ein Beispiel zur Veranschaulichung: Das Outcome 1. (siehe beschrifteter Pfeil in Abbildung 3) fordert als Ergebnis der Aktivität [SPR.1_BP.1] „Create problem reports“ die Erstellung von Problemberichten [B1.46] als Artefakte für jeden festgestellten Softwarefehler ein. Diese Artefakte werden ebenso von den Outcomes 2. und 4. weiter verfeinert.
Das Ergebnis wiederum lässt sich in Hinblick auf das Prozessattribut PA 1.1 (siehe Abschnitt zu Prozessbefähigung, Reifegradstufen und Prozessattribute) bewerten, um ein Assessment zur Erreichung des Reifegrads Level 1 als durchzuführen.
Prozess des Managements von Softwareänderungen - SPR.2
Der Prozess des Managements von Softwareänderungen SPR.2 macht es sich zum Ziel, den Übergang von SPR.1- also der investigierten Lösung des Softwareproblems – hin zu einem gelenkten und nachverfolgbaren Änderungsverfahren der betroffenen Elemente der Software zu vollziehen.
Abbildung 4 zeigt die sechs Basispraktiken SPR.2_BP.1…6, welche dieser Prozess bedient.
Die Änderungsanforderung [B1.55] (erzeugt in dem vorgelagerten Problemlösungsprozess SPR.1 (s.o.)) – ist der Input der Basispraktik zur Genehmigung der Änderungsanderforderungen ([SPR.2_BP.1] „Approve change requests“).
Die erteilte Genehmigung der anhängigen Änderungsanforderungen
- erfüllt das Ergebnis „Outcome 1. – Change requests are approved”
(Rechts-Pfeil 1.), - vermerkt die erteilte Genehmigung als aktualisierten Status in der Änderungsanforderung
(Links-Pfeil 1.) und - erlaubt damit die Implementierung der Änderung ([SPR.2_BP.2] „Implement changes“).
Zusammenfassung
Die Technische Regel VDI 5702-Blatt 1:2026 - Medical SPICE® [1] gibt den Rahmen der Prozessbewertung der Software-Entwicklung vor und stellt die Minimalanforderungen an die Durchführung einer Bewertung auf, um die Konsistenz und Wiederholbarkeit der Bewertungen zu gewährleisten.
Ein Kernstück dieser Richtlinie ist das reifegradbasierte Prozessbewertungsmodell gemäß ISO/IEC 3300x etc. [10], um mit dessen Nutzung umfassende Bewertungen der Softwareprozessfähigkeit der Organisation und allen Prozessen des Software-Lebenszyklus medizinischer Produkte und Health-Software vornehmen zu können.
Ausblick
Hat dieser Artikel deine Neugier auf Medical SPICE® in der hier vorgestellten aktuellen Edition geweckt?
Willst du mehr über das Prozessreferenz- und -assessment-Modell nach VDI 5702-Blatt 1:2026-01 - Medical SPICE® wissen?
Beabsichtigst du, dieses Prozessmodell in deinen aktuellen oder zukünftigen Health Software Projekten anzuwenden?
Oder möchtst du das in dem Modell hinterlegte Bewertungsschema im Rahmen von Software-Lieferantenaudits oder Gap-Analysen zielführend und effizient nutzen?
Dann solltst du neben dem Hauptteil (Blatt 1) auch die Aspekte in Blatt 2 [2] und Blatt 3 [3] der Richtlinie in deine Betrachtungen einbeziehen. Die beiden nächsten Unterabschnitte geben einen kleinen Einblick auf diese Ergänzungen.
Falls du über die VDI 5702 hinaus generelle Unterstützung bei der Qualitätssicherung und Zulassung von Medizinprodukten bzw. Health Software benötigst, so zögere nicht uns zu kontaktieren; die qtec group bietet zahlreiche Dienstleistungen sowie hochqualifizierte Experten in den Domänen des Design Control [11] und des Qualitätsmanagements [12] an!
Blatt 2 - Qualifizierung von Entwickelnden und Assessoren
Die Experten, die Assessments gemäß Blatt 1 nach hohen Qualitätsstandards durchführen, müssen qualifiziert und befähigt sein. Dazu definiert das Blatt 2 die Rahmen und Kriterien der Qualifizierung von Assessor:innen.
Blatt 3 - Medical SPICE® - Empfehlungen für die Softwareentwicklung
In Blatt 3 werden für die wichtigsten Basiselemente einige Best Practices im Sinne der guten fachlichen Praxis vorgestellt. Diese Richtlinie unterstützt damit die Beherrschung der Softwareentwicklungsprozesse auf einem hohen Niveau. Das Blatt 3 richtet sich damit an
- Softwareentwickler:innen,
- Entwicklungsleiter:innen,
- Prozessmanager:innen,
- Regulatory-Affairs-und-Qualitätsmanager:innen,
die im Bereich der Entwicklung, Herstellung und Zulassung von Health-Software beschäftigt sind.
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.
Glossar der wichtigsten Begriffe zu Medical SPICE® (DE,EN)
| Begriff [DE] | Term [EN] | Akronym |
|---|---|---|
| Arbeitsprodukt | Working Product | WP |
| Basispraktik | Base Practice | BP |
| (elektronische) Entwicklungsakte | (electronic) Design History File | (e)DHF |
| Prozessattribut | Process Attribute | PA |
| Prozessbewertungsmodell | Process Assessment Model | PAM |
| Prozessdimension | Process Dimension | PD |
| Prozessgruppe | Process Group | PG |
| Prozessreferenzmodell | Process Reference Model | PRM |
| Prozessverbesserung und Bestimmung der Prozessfähigkeit in der Softwareentwicklung | Software Process Improvement and Capability Determination | SPICE |
| - | Capability Dimension | CD |
| Software-Entwicklung | Software Development | SD |
| Software-Konfigurationsmanagement | Software Configuration Management | SCM |
| Software-Problemlösung | Software Problem Resolution | SPR |
| Software-Wartung | Software Maintenance | SM |
| Standalone-Software-Entwicklung | Standalone Software Development | SSD |
Quellenangaben
1VDI 5702 Blatt 1:2026-01 - Medizinprodukte-Software - Medical SPICE - Prozessassessmentmodell
5IEC 62304:2006+AMD1:2015 CSV - Medical device software - Software life cycle processes
7ISO 14971:2019 - Medical devices - Application of risk management to medical devices
8IEC 82304-1:2016 - Health software - Part 1: General requirements for product safety
11qtec group – Design Control - Software-Qualitätssicherung
12qtec group – Qualitätsmanagement - Software-Lebenszyklus-Prozesse
13iNTACS - International Assessor Certification Scheme e.V. - SPICE Center
Unser Newsletter „qonzentrat“
kompakt, professionell und präzise
Profitieren Sie von unserem Fachwissen.
Jetzt anmelden
