Health-Software: Medical SPICE® (VDI 5702-Sheet 1:2026)
How to successfully check and manage software life cycles with the help of the Medical SPICE® assessment model (VDI 5702-Sheet 1:2026)
In this article, you will learn how you can use the maturity-based process model Medical SPICE® for your health software projects and life cycles. Since January 2026, the new edition of the Technical Rule VDI 5702-Part 1 has updated some aspects compared to the first edition of 2017. It is therefore worthwhile taking a closer look at this guideline.
Introduction
The importance of high-quality software in medical technology cannot be overstated. Along the entire life cycle of software-based medical devices, a number of processes are intertwined, which in turn produce a large number of documents and records.
The applicable, harmonized standards (see section Normative context) refer to each other, but unfortunately also generate redundancies in the procedure and the documents.
A significant claim of the Directive VDI 5702-Sheet 1 - Medical SPICE® is to identify and eliminate these redundancies, which can reduce the expenses in the execution of processes and document creation significantly reduced – and thus also the SPOT principle (Single Point of Truth), see section Normative context.
Another basic element of the VDI 5702-Part 1 the application of a Process Assessment Model (PAM), see section What is SPICE?. This PAM is ideally suited as an evaluation scheme for example supplier audits of service providers / contractors - but also for internal audits.
A third and key benefit of the Directive is the transferability of the PAM to a Process Reference Model (PRM), which enables you to create an own and standard-compliant process model consisting of elementary Base Practices and Work Products , see section Process groups, base practices and work products in Medical SPICE®.
Normative context
As described above, Medical SPICE® avoids the redundant execution of the same or similar process steps, which are required by the board in these standards. For the newly published second edition of VDI 5702-Part 1 [1], these are:
The updated editions of the referenced standards compared to 2017:
- IEC 60601-1:2020-08 (Ed. 3.2) [4]
Medical electrical equipment - Part 1: General requirements for basic safety and essential performance - IEC 62304:2015-06 (Ed. 1.1) [5]
Medical device software - Software life cycle processes - IEC 62366-1:2020-06 (Ed. 1.1) [6]
Medical devices - Part 1: Application of usability engineering to medical devices
The following standards have been added compared to the 2017 edition:
- IEC 82304-1:2016-10 [8]
Health software - Part 1: General requirements for product safety - IEC 81001-5-1:2021-12 [9]
Health software and health IT systems safety, effectiveness and security- Part 5-1: Security - Activities in the product life cycle
In the appendix to the guideline, the mapping of the requirements by Medical SPICE® to the above standards is discussed in detail.
It is important to mention that VDI 5702 Part 1 does not "create" any new normative requirements; it therefore forms a redundancy-free and structured compilation of all clauses of the standards listed above.
The guideline is written bilingually in DE and EN.
Time constraints, a lack of resources, or increasing regulatory requirements?
We provide you with the right experts for your medical device projects — quickly, qualified, and with proven project experience.
What is SPICE?
Since the end of the 1990s, maturity-based process frameworks such as SPICE (1998) and CMMI (2002) have been established in the industry. The aim is to continuously improve software development processes on the one hand, but also capability determination in an existing process landscape on the other.
The acronym SPICE stands for "Software Process Improvement and Capability Determination"; the
corresponding standard ISO/IEC 15504-1 has now been replaced by ISO/IEC 33001 - and ISO/IEC 15504-2 by ISO/IEC 33002 [10] (and other standards in this number range).
As a rule, related software processes (along the SW life cycle) are clearly named and thematically summarized in process groups. The evaluation is carried out according to a two-dimensional scheme: On the one hand, there is the Process Dimension (PD), along the axis of which all processes involved and to be evaluated are arranged; and on the other hand, there is the axis of the Capability Dimension (CD).
Process capability, maturity levels and process attributes
For each process along the PD axis, the capability is determined on the basis of the respective Process Attributes (PA) and thus a division into maturity levels along the CD axis is achieved:
Each of these levels requires process attributes to be evaluated differently – with the exception of Level 0, which, as an incomplete process, has no or hardly any evidence to offer as proof of process capability.
Level 1 shows to which each individual (sub-)process is executed and proven as a result of the evaluation of the process attribute PA 1.1. This is the core of SPICE. Specific to the respective field, Base Practice (BP) as a process step and Work Products (WP) are evaluated and used to determine process capability.
Unified rating scale
The following, unified rating scale according to ISO/IEC 33001 is used.
Each process attribute considered can be evaluated using indicators per degree of fulfillment {F, L, P, N}.
| Symbol | Degree of fulfillment | Quantitative | Description |
|---|---|---|---|
| F | Fulfilled | >85% … 100% | There are indications of a complete and systematic approach and full fulfillment of the defined process attribute in the evaluated process. There are no significant weaknesses in the evaluated process regarding the process attribute. |
| L | Largely fulfilled | >50% … 85% | There are indications of a systematic approach and a significant fulfillment of the defined process attribute in the evaluated process. In the evaluated process, there may be some weaknesses regarding the process attribute. |
| P | Partially fulfilled | >15% … 50% | There are some indications of an approach and partial fulfillment of the defined process attribute in the evaluated process. Some aspects of meeting the process attribute can be unpredictable. |
| N | Not fulfilled | 0% … 15% | There are no or little signs of fulfillment of the defined process attribute in the evaluated process. |
As already described, the process attribute PA 1.1 is used for the goal of achieving maturity level level 1. For this purpose, the requirements for each base practice must be fulfilled by more than 50%, i.e. they must be rated by fulfillment level F or L.
In this article, we will limit ourselves to Level 1, as it is precisely here that all base practices and work products for the lifecycle of medical device software are referenced.
Higher maturity levels
Level 2 to 5 (with further process attributes), on the other hand, indicate how consistently the assessed organization adheres, observes, and improves the processes over the entire life cycle. defined and executed in level 1.
SPICE in different domains and areas of knowledge
In the next chapter, the specialization of the generic SPICE framework - applied to the field of medical device software - will be discussed: Medical SPICE®.
However, there are also other domain specializations, here is just a selection:
- Automotive SPICE (ASPICE)
The ISO 26262 standard (Road vehicles – Functional safety) describes a process model based on the SPICE framework. - Hardware SPICE
applied to the development of (electrical/electronic) hardware. - Mechanical SPICE
SPICE applied to the development of mechanical elements. - TestSPICE
The scope of TestSPICE covers testing of software and systems as well as related testing activities. - Modeling & Simulation SPICE
SPICE applied to the evaluation of process capability in the development of credible simulation models.
The assessor certification portal iNTACS [13] provides a good overview of SPICE and other helpful information.
Process groups, base practices and work products in Medical SPICE®
At Medical SPICE®, the life cycle of software in medical technology is divided into processes, which in turn are grouped into process groups.
Overview of Process Groups in Medical SPICE®
The SD process group
- is divided into processes for the development of software as a component of medical devices, in terms of planning, requirements, architecture, design, implementation, verification, release and risk management.
- To get a better feel for the increased scope of the new edition of VDI 5701-Sheet1 compared to the first edition of 2017, we also present a few key figures here: The SD process group references 10 processes, in total
- 66 Base Practices in the First Edition of VDI 5702-Part 1
- 84 Base Practices in the Second Edition of VDI 5702-Part
The SDD process group
- expands the SD process group to include processes that are also required for the development of standalone software (Software as a Medical Device, SaMD). In particular, software validation comes into play here.
- This references 7 processes with a total of
- 41 Base Practices in the First Edition of VDI 5702-Part 1
- 46 Base Practices in the Second Edition of VDI 5702-Part 1
The SM Process Group
- includes processes that determine the life cycle after the first release of the software, i.e. typically the phases of maintenance and further development.
- This references 3 processes with a total of
- 15 Base Practices in the First Edition of VDI 5702-Part 1
- 19 Base Practices in the Second Edition of VDI 5702-Part 1
The SCM process group
- provides software configuration management processes needed to support the development and maintenance phases.
- This references 2 processes with a total of 12 base practices.
The SPR process group
- includes software problem resolution processes that also support development and maintenance activities.
- This references 2 processes with a total of 13 base practices.
Thus, the five process groups define in total:
- 147 base practices with a total of 70 work products in the first edition of VDI 5702-Part 1
- 174 base practices with a total of 80 work products in the second edition of VDI 5702-Part 1
Overview of work products (excerpt)
The work products are extractable artifacts that are (also) stored in the (e)DHF, for example:
- Plans such as [B1.02] Software development plan,
- Lists like [B1.28] Known anomaly list,
- Specifications such as [B1.13] Software requirements,
- Reports, such as [B1.53] Risk management report,
- Records like [B1.40] Software build record
- but also outsourced processes or activities such as [B1.51] Risk management process.
Insights: The Software Problem Resolution Processes - SPR
Let us take a look at the software problem resolution process group SPR more precisely. This consists of two processes: on the one hand, the core SPR.1 Problem Resolution Process and on the other hand, the supportive Software Change Management Process SPR.2. The Figure 5 stands for this connection.
Problem Resolution Process - SPR.1
This process deals with the analysis of the SW problem at hand. The term "problem" includes any anomalies and deviations that are detected throughout the software lifecycle, including the development phase.
The Figure 6 shows the seven base practices SPR.1_BP.1... 7 (here modeled as an activity), which can be used in the context of the process of software problem resolution SPR.1 should be executed in the sequence of numbering. Six of these base practices produce (in this case) four work products.
The connections can be read directly from the depicted view. Example: The base practice for creating the change request ([SPR.1_BP.6] "Create change request") creates
- the record of problem investigation [B1.59] "Problem investigation record" and
- the change request [B1.55] "Change request".
The process is considered fulfilled as soon as the required seven outcomes can be proven.
The concept of "outcome" combines the existence of the associated documents with the implementation of the associated base practices; it is therefore about the conditions achieved and verifiable criteria – the "Definition of Done", so to speak.
An example to illustrate: The Outcome 1. (see inscribed arrow in Figure 6) calls for the Result of the activity [SPR.1_BP.1] "Create problem reports" Preparation of problem reports [B1.46] as artifacts for each software bug detected. These artifacts are also further refined by outcomes 2 and 4.
The result, in turn, can be compared with regard to the Process Attribute PA 1.1 (see section on Process capability, maturity levels and process attributes) in order to carry out an assessment to achieve maturity Level 1 than to carry out.
Software Change Management Process - SPR.2
The process of software change management SPR.2 aims to make the transition from SPR.1 – the investigative solution to the software problem – to a controlled and traceable change process of the affected elements of the software.
Figure 7 shows the six base practices SPR.2_BP.1... 6 that this process serves.
The change request [B1.55] (generated in the upstream problem-solving process SPR.1 (see above)) – is the input of the base practice for approving the change requests ([SPR.2_BP.1] "Approve change requests").
The granted approval of pending change requests
- satisfies the result "Outcome 1. – Change requests are approved" (right arrow 1.),
- notes the granted approval as an updated status in the change request
(left arrow 1.) and - thus allows the implementation of the change ([SPR.2_BP.2] "Implement changes").
Conclusion
The Technical Rule VDI 5702-Sheet 1:2026 - Medical SPICE® [1] provides the framework for the process evaluation of software development and sets the minimum requirements for conducting an evaluation to ensure consistency and repeatability of the evaluations.
A core element of this guideline is the maturity-based process assessment model according to ISO/IEC 3300x etc. [10] in order to be able to use it to carry out comprehensive assessments of the software process capability of the organization and all processes of the software life cycle of medical products and health software.
Outlook
Has this article aroused your curiosity about Medical SPICE in the current edition presented here?
Would you like to know more about the process reference and assessment model according to VDI 5702-Sheet 1:2026-01 - Medical SPICE®?
Do you intend to apply this process model for your current or future health software projects?
Or would you like to use the evaluation scheme stored in the model in a targeted and efficient way as part of software supplier audits or gap analyses?
In addition to the main part (sheet 1), you should also include the aspects in sheet 2 [2] and sheet 3 [3] of the guideline in your considerations. The next two subsections give a small insight into these additions.
If you need general support addition to VDI 5702 with regards to quality assurance and approval of medical devices or health software, please do not hesitate to contact us; the qtec group offers numerous services as well as highly qualified experts in the domains of design control [11] and quality management [12]!
Sheet 2 - Qualification of Developers and Assessors
The experts who carry out assessments according to sheet 1 with regards to high quality standards must be qualified and capable. To this end, sheet 2 defines the framework and criteria for the qualification of assessors.
Sheet 3 - Medical SPICE® - Recommendations for Software Development
In sheet 3, some best practices in terms of good professional practice are presented as the most important basic elements. This guideline thus supports the mastery of software development processes at an elevated level. Sheet 3 is thus aimed at:
- Software developers,
- Development department managers,
- Process managers,
- Regulatory Affairs and Quality Managers,
who are involved in the development, manufacture and approval of health software.
Does this sound familiar?
Then let’s talk about it. Our experts are well acquainted with these challenges—and support MP manufacturers in a flexible, pragmatic, and collaborative manner.
Glossary of the most important terms related to 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 |
References
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
