MDevSPICE (Medical Device SPICE): MDevSPICE – Tutorial (about 60 minutes)

MDevSPICE® (Medical Device SPICE) is a process assessment framework for organisations that develop software for medical devices. It brings the requirements of the main medical device software standards and guidance, led by IEC 62304, into the two-dimensional SPICE assessment structure, so that one assessment shows both how capable a company's software processes are and where they fall short of regulatory expectations. It is used by software suppliers preparing for regulatory audits, by manufacturers improving their own development, and by manufacturers judging whether a supplier can be trusted with safety-related software. After this tutorial you will be able to explain how MDevSPICE is built, read an MDevSPICE-style capability profile, and plan a sensible first assessment and improvement cycle.

Free tutorial · about 60 minutes · 7 lessons · 4 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: MDevSPICE is not an ISO or IEC standard. It is a domain-specific process reference model, process assessment model, assessment method and assessor training scheme developed by the Regulated Software Research Centre (RSRC) at Dundalk Institute of Technology in Ireland, with support from Lero, the Irish software research centre. It grew out of earlier work called Medi SPICE, was released to industry from late 2014, and is described in peer-reviewed papers published between 2014 and 2018 (for example Lepmets, McCaffery and Clarke, "Development and benefits of MDevSPICE®", Journal of Software: Evolution and Process, 2016). The full model is not published openly and carries no public version number; we found no newer public release or announced revision as of the verification date. The model was built on ISO/IEC 15504 (since replaced by the ISO/IEC 330xx family) and on the editions of the medical device standards current at the time, several of which have since been revised: IEC 62304 now stands as the 2006 edition with its 2015 amendment (a second edition is in development at IEC and is not published), ISO 13485 is the 2016 edition, ISO 14971 the 2019 edition, and the EU Medical Device Regulation and the US FDA Quality Management System Regulation have replaced the regulations the papers cite. This tutorial teaches the model as published and tells you where you must map it to today's editions. Verified 2026-10-29 from the RSRC authors' papers in the DCU repository, the IEC webstore and standards catalogues.

Who it is for: software engineers, quality and regulatory affairs staff, project managers and supplier-quality people in medical device companies or in software firms that want to supply them, and process improvement specialists who already know SPICE from another sector and want to apply it in healthcare.

Prerequisites: none. A general idea of how software projects are planned, built and tested will help. Every medical device and SPICE term is explained when it first appears.

By the end of this tutorial:

You will be able to explain why MDevSPICE was created and what problem it solves that a regulatory audit alone does not.
You will be able to name the standards and guidance it integrates and say which one is always in scope.
You will be able to describe the structure of the reference model and the assessment model, including the three process groups and the elements of each process.
You will be able to apply the capability levels, process attributes and N-P-L-F rating scale to derive a capability level.
You will be able to plan a full or lightweight MDevSPICE assessment, with roles, scope and a target profile.
You will be able to turn assessment findings into a focused improvement plan for a medical device software team.
You will be able to position MDevSPICE against IEC 62304, ISO 13485, ISO/IEC 330xx, Automotive SPICE and VDI 5702 Medical SPICE.

Lesson 1 – Origins, purpose and scope

Why medical device software needed its own SPICE

Software now sits inside infusion pumps, pacemakers, imaging systems and patient monitors, and it can also be a medical device on its own, for example an app that calculates insulin doses. When such software fails, patients can be harmed. Regulators therefore require manufacturers to show that their software was developed under controlled processes before a device may be sold. In Europe this is done through the Medical Device Regulation and CE marking; in the United States through the Food and Drug Administration (FDA) and its quality system rules; other markets have their own authorities.

To meet these rules, manufacturers follow a group of international standards. IEC 62304 defines the software life cycle processes for medical device software. ISO 13485 defines the quality management system. ISO 14971 defines risk management for medical devices. IEC 62366 covers usability engineering, IEC 60601-1 covers the safety of medical electrical equipment, and IEC 82304-1 covers health software products that run on general-purpose computers. On top of these come regulator guidance documents, such as the FDA's guidance on software validation, on off-the-shelf software and on premarket submissions.

The RSRC researchers who created MDevSPICE observed two problems. First, software companies entering the medical device market were overwhelmed by the number of overlapping standards and did not know where to start. Second, the industry relied mainly on audits, which give a pass or fail answer against a set of requirements. An audit tells you whether you comply today; it does not tell you how robust your processes are, how they compare with general software engineering good practice, or what to improve first. Their published motivation also pointed to a rising share of device recalls linked to software faults.

The SPICE answer

Other safety-critical sectors had already solved a similar problem with SPICE, the process assessment approach standardised as ISO/IEC 15504 and now continued as ISO/IEC 330xx. The car industry, for example, created Automotive SPICE so that carmakers could assess suppliers in a common way. A SPICE assessment rates each process on a capability scale and produces a profile of strengths and weaknesses that drives improvement. The RSRC team set out to build the same kind of model for medical devices, first under the name Medi SPICE and from 2014 as MDevSPICE. The "SPICE" in the name signals that foundation.

The key design idea is that MDevSPICE combines two things that are normally separate: compliance (does the process meet what IEC 62304, ISO 14971 and the others require?) and capability (how well managed, defined and repeatable is the process?). One assessment gives an organisation both views.

Scope and purposes

MDevSPICE covers the processes needed to develop and maintain regulatory-compliant medical device software: system-level processes for when software is part of a larger device, software life cycle processes from IEC 62304, and supporting processes. The published papers name three main purposes for an assessment:

A process evaluation before a regulatory audit, to find and fix weaknesses while there is still time.
A gap analysis inside an internal process improvement programme.
A capability determination, in which a manufacturer checks whether a software supplier is suitable to develop software for its devices.

What MDevSPICE is not matters just as much. It does not certify an organisation against IEC 62304 or any other standard, and it does not replace a notified body audit or an FDA inspection. Its authors describe the compliance view as a reasonably accurate approximation that helps companies prepare, not as a formal verdict.

Figure 1 – MDevSPICE builds its reference model from IEC 62304, ISO/IEC 12207, ISO 13485 and ISO 14971, then adds practices, product, usability and FDA requirements and the ISO/IEC 15504-2 capability scale to form the assessment model.

Lesson 2 – Key concepts and vocabulary

MDevSPICE uses SPICE vocabulary and medical device vocabulary side by side. The authors deliberately kept the medical device terms that regulators and practitioners already use, because generic software terminology differs in places. Learn these terms before going further:

Medical device software – software that is itself a medical device or is part of one; the subject of IEC 62304.
Software safety class – the IEC 62304 classification (A, B or C) based on the worst harm a software failure could contribute to: no injury possible, non-serious injury possible, or death or serious injury possible. The class decides how much process rigour IEC 62304 demands.
SOUP – software of unknown provenance: software already developed, such as an operating system or open-source library, that was not built under the manufacturer's controlled process. Both IEC 62304 and FDA guidance on off-the-shelf software require special handling.
Process reference model (PRM) – a catalogue of processes, each described only by a name, a purpose and its outcomes. It says what a process must achieve, not how.
Process assessment model (PAM) – the assessors' working model. It takes the processes of the PRM, adds indicators such as base practices and work products, and adds a capability scale.
Process purpose – a short statement of the high-level objective of a process.
Process outcome – an observable result of achieving the purpose. In MDevSPICE the outcomes are the normative requirements of a process.
Base practice – an activity that shows one possible way of achieving the outcomes. Base practices are informative: an organisation may reach the outcomes another way.
Work product – an artefact used or produced by a process, such as a software development plan, a requirements specification or a test record. Each is described by work product characteristics, its expected content.
Normative work product – a work product that a medical device standard explicitly requires. Unlike general SPICE models, MDevSPICE treats some work products as mandatory.
Capability level – one of six steps, 0 to 5, describing how well a process is performed and managed.
Process attribute – a measurable property of process capability, such as performance management; each level beyond 0 has one or two.
Generic practice – an indicator showing that a process attribute is achieved; it applies to any process.
Process profile – the set of attribute ratings for the processes assessed; a target profile is the set of levels an organisation or customer wants.
Assessment sponsor – the person or body that requests the assessment and provides resources; can be inside the assessed organisation or outside it, for example a customer.
Process lineage – the MDevSPICE practice of marking each outcome, base practice or note with the standard or guidance it came from.

Assessment versus audit

The difference between an assessment and an audit is the concept that unlocks the whole model. An audit compares evidence with requirements and records conformities and nonconformities; its result is essentially yes or no for each requirement. An assessment rates the extent to which processes achieve their purpose and how well they are managed, on a graded scale, and highlights strengths as well as weaknesses. Audits remain essential for market access. Assessments are a preparation and improvement tool that also lets a customer compare suppliers on a common scale.

Compliance and capability together

Imagine two companies that both pass an IEC 62304 audit. One relies on a single expert who remembers what to do; the other has a defined, trained and monitored process. Both comply today, but the second is far less likely to slip when people leave or projects grow. MDevSPICE makes that difference visible through capability levels, while the lineage tags let the same evidence show coverage of each standard.

Lesson 3 – Structure of the reference and assessment models

How the reference model was assembled

The heart of the process reference model is IEC TR 80002-3, a technical report published in 2014 that turns the IEC 62304 software life cycle into a SPICE-style process reference model. The MDevSPICE authors led its development within the IEC committee responsible for IEC 62304. The report's processes correspond to the IEC 62304 processes and keep their safety class distinctions.

Because IEC 62304 deals only with software, the authors added system-level processes derived from ISO/IEC 12207:2008 for situations where software is part of a larger device, so that requirements can be traced from the device down to the software. They then folded in design and development requirements from ISO 13485 and risk management requirements from ISO 14971. The process descriptions follow the format of ISO/IEC 24774, the guide to writing process descriptions, with a name, a purpose and outcomes.

Two integration decisions are worth knowing. First, ISO 14971 spreads risk management across the whole life cycle. To avoid repeating the same requirements in every process, MDevSPICE keeps them in a single software risk management process and adds an annex table listing the risk-related requirements for each life cycle process. If an assessment does not include risk management in full, those requirements are added to the processes that are assessed. Second, ISO 13485 requirements were added as new outcomes where no matching outcome existed, or as notes where one did. Some quality system requirements concern how a process is managed rather than what it produces, such as allocating resources or controlling documents. These were linked to the generic practices of capability Level 2, under the attributes for performance management and work product management.

Three process groups

The published papers from 2015 and 2016 describe 23 processes in three groups (a 2014 paper, written while the model was still being finalised, mentions 24):

System life cycle processes (10) – system-level and project work drawn from ISO/IEC 12207:2008, needed when software is a subsystem of a device: project planning, project assessment and control, risk management at system level, stakeholder requirements definition, system requirements analysis, system architectural design, system integration, system qualification testing, software installation and software acceptance support.
Software life cycle processes (8) – the software development activities of IEC 62304, from software development planning and software requirements analysis through architectural design, detailed design, unit implementation and verification, integration and integration testing, to software system testing, plus software risk management, the process that carries the ISO 14971 requirements.
Support processes (5) – processes that serve both system and software work: configuration management, software release, software problem resolution, software change request management and software maintenance.

Inside a process

In the assessment model every process is described by the same elements: process name, process purpose, process outcomes, base practices, work products and work product characteristics. The outcomes are normative. The base practices are informative, and in MDevSPICE they were drawn from different sources depending on where the outcome came from. Where an outcome came from ISO/IEC 12207, its practices and work products came from the exemplar assessment model ISO/IEC 15504-5. Where it came from ISO 14971, the practices came from IEC TR 80002-1, the guidance on applying ISO 14971 to medical device software. FDA guidance on premarket submissions, software validation and off-the-shelf software was added to base practices that did not already cover it. Product safety requirements from IEC 60601-1 and the health software standard IEC 82304-1, and usability requirements from IEC 62366, were also incorporated.

Lineage tags make the sources visible. For instance, a base practice on describing the software architecture carries an added note from the FDA off-the-shelf software guidance about identifying the design limitations of SOUP, and the requirements verification practice carries a note from the FDA validation guidance about tracing software requirements to and from risk analysis results. Outcomes that come from IEC 62304 also state the software safety classes for which they apply, so an assessor knows which outcomes matter for Class A, B or C software.

The capability dimension

Like ISO/IEC 15504-5, the assessment model is two-dimensional. The process dimension contains the processes just described. The capability dimension comes directly from the ISO/IEC 15504 measurement framework: capability levels, process attributes, generic practices, generic resources and generic work products. Lesson 5 explains how it is used to rate.

Figure 2 – The assessment model has a process dimension of three process groups, each process described down to work products, and a capability dimension of levels, attributes and generic indicators.

Lesson 4 – How it works in practice

What changes for the development team

MDevSPICE does not prescribe a development method. A team may work in phases, iteratively or with an agile framework such as Scrum, as long as the process outcomes are achieved and the required evidence exists. The RSRC group later published work on fitting agile practices into MDevSPICE-assessed development, including a 2018 hybrid approach that combines an MDevSPICE-based assessment with value stream mapping to prioritise improvement needs and the Kata coaching routine to carry out improvements step by step. The message is that the model describes results and evidence, not ceremonies.

Typical artefacts and their links

Because the model integrates several standards, a team preparing for an assessment usually checks a familiar chain of artefacts:

A software development plan that names the life cycle model, deliverables, the safety class and how risk management, configuration management and problem resolution will be done.
Software requirements, including those that implement risk control measures, traced to system requirements and to risk analysis results.
An architecture that identifies software items, interfaces and SOUP, with the expected limitations of each SOUP item.
Detailed design and unit verification records to the depth the safety class demands.
Integration and system test plans and records, with traceability from requirements to tests.
A risk management file showing hazards, causes involving software, risk controls and verification of those controls.
Configuration items, baselines and change records, and a problem resolution record for each reported problem.

Roles

Three roles appear in every MDevSPICE assessment. The sponsor requests the assessment and provides the money and people; it may be the assessed company or a customer who wants to evaluate a supplier. The lead assessor (called a principal assessor when qualified to lead third-party assessments) is responsible for planning, conduct and results. Further assessors join the lead to form the assessment team. Inside the organisation, practitioners such as developers, testers, the quality manager and the risk manager take part as interviewees and provide evidence.

The assessment team must understand the reference model, the assessment model and the medical device standards behind them. It must also understand the organisational unit being assessed, its culture and, where relevant, its different sites.

Scoping an assessment

Scoping is where MDevSPICE differs most from a generic SPICE assessment. The team decides which processes to include and which standards and guidance documents to take into account. IEC 62304 is always in scope, because it is the foundation of the model. The other standards and guidance can be included or left out depending on the device, the market and the purpose. The safety class of the software matters too, because it decides which IEC 62304-derived outcomes apply. A company building Class A software for a European market will scope differently from one building Class C software sold in the United States.

From findings to improvement

The output of an assessment is a report with process profiles, a comparison with the target profile, strengths, weaknesses and recommendations. Pilot companies valued a graphical view of coverage per standard alongside the text findings. The organisation then turns the findings into a process improvement plan, implements it and, ideally, has the processes reassessed to confirm progress. Seen this way, MDevSPICE is less a one-off test than a repeating cycle of assessing, improving and reassessing.

Figure 3 – The seven stages of an MDevSPICE-Adept lightweight assessment, from the first meeting to reassessment after the improvement plan.

Lesson 5 – Assessment, ratings and recognition

The capability scale

MDevSPICE uses the six-level capability scale of the ISO/IEC 15504-2 measurement framework, which continues in revised form in ISO/IEC 33020. Each level above 0 is defined by one or two process attributes:

Level 0, Incomplete – the process is not performed or does not achieve its purpose.
Level 1, Performed – the process achieves its outcomes (attribute PA 1.1 Process performance).
Level 2, Managed – the process is planned, monitored and adjusted, and its work products are controlled (PA 2.1 Performance management and PA 2.2 Work product management).
Level 3, Established – the process follows an organisation-wide standard process that is tailored and deployed (PA 3.1 Process definition and PA 3.2 Process deployment).
Level 4, Predictable – the process operates within quantitative limits (PA 4.1 Process measurement and PA 4.2 Process control in 15504-2 terms).
Level 5, Optimizing – the process is continuously improved to meet current and future business goals (PA 5.1 Process innovation and PA 5.2 Process optimization). ISO/IEC 33020 renamed some higher-level attributes and calls Level 5 Innovating.

For medical device software, Level 1 is roughly where regulatory compliance sits: the outcomes are achieved and the required work products exist. Level 2 and above say how reliably that happens. The papers mention reaching capability Level 3 as one possible improvement goal.

Rating process attributes

Assessors rate each attribute on the four-point N-P-L-F scale: Not achieved (0 to 15 per cent), Partially achieved (above 15 up to 50 per cent), Largely achieved (above 50 up to 85 per cent) and Fully achieved (above 85 up to 100 per cent). A process reaches a level when the attributes of that level are rated Largely or Fully achieved and all attributes of the lower levels are rated Fully achieved. So a process with PA 1.1 Fully, PA 2.1 Largely and PA 2.2 Largely is at Level 2; if PA 1.1 were only Largely, it would stop at Level 1 however good its management looked.

Ratings must rest on objective evidence. For PA 1.1 the assessors look at outcomes, base practices and work products, including the normative work products that a medical device standard requires. For higher attributes they look at generic practices, such as planning and monitoring the process, defining responsibilities, providing resources and reviewing work products.

Assessment rigour and the lightweight method

The amount of evidence required depends on the purpose of the assessment and its class: the more rigorous the class, the more evidence is collected and the more experienced the assessors must be, which also makes the assessment longer and costlier. The full MDevSPICE method has five main phases running from planning the assessment to reporting results, and uses a scripted question set linked to the assessment model so that every scoped standard is covered consistently.

Because a full assessment needs significant planning and resources, the RSRC also developed MDevSPICE-Adept, a lightweight method. Industry experts chose 11 processes, most of them from IEC 62304, as the default selection, so that the on-site part could take no more than two days. Two assessors share the work: the lead asks the scripted questions and the second assessor takes notes and asks follow-up questions. Up to five processes are covered per day, with interviews of roughly an hour per process. The Adept method focuses on the process dimension and on improvement, not on formal certification. The selection can be extended to more processes if the company accepts a longer on-site visit.

Assessor qualification

The MDevSPICE assessor certification scheme described by the authors has three grades: MDevSPICE assessor, lead assessor, and principal assessor, the last being a lead assessor qualified to perform third-party assessments. The 2015 pilot paper described assessor training and certification as about to begin. We could not find a public register of certified MDevSPICE assessors as of 2026-10-28, so anyone planning a formal assessment should ask the RSRC directly what is currently offered.

What results mean for compliance

An MDevSPICE assessment does not certify compliance with IEC 62304, ISO 13485 or any other standard, and no regulator is obliged to accept its results. Its authors expressed the hope that regulators might one day recognise results, but that has not been established. What it does provide is a capability rating per process plus a structured list of gaps against the scoped standards, which a company can close before its notified body audit or FDA inspection.

Figure 4 – The six capability levels of the MDevSPICE capability dimension, each built on the one below and defined by its process attributes.

Lesson 6 – Worked example: a supplier prepares for a customer assessment

The following organisation is fictional, but every step reflects how the published method is meant to be used.

The situation

Brightwater Analytics is a 70-person software company that has built data platforms for hospitals. A large infusion pump manufacturer wants Brightwater to develop the dose-calculation module for a new pump. A wrong dose can seriously injure a patient, so the manufacturer's risk analysis gives this software item safety Class C. Before signing a contract, the manufacturer wants evidence that Brightwater can develop software to medical device expectations. Brightwater has an ISO 9001 quality system and good engineering habits, but no medical device experience.

Step 1 – Agree purpose, sponsor and scope

The manufacturer is the sponsor and the purpose is capability determination. It sets a target profile: Level 2 for software development planning, software requirements analysis, software architectural design, software system testing, software risk management and software configuration management, and Level 1 for the remaining IEC 62304 processes. IEC 62304 is in scope by default; the parties also include ISO 14971 (through the risk management process) and the FDA guidance on off-the-shelf software, because the module will use a third-party maths library. Since Brightwater has six months before the contract decision, its management decides to commission a lightweight assessment of its own first.

Step 2 – Lightweight first-party assessment

Brightwater engages two external assessors familiar with the model for a two-day Adept-style assessment of ten processes. Interviews follow the life cycle order, from planning to system testing, because pilot assessments found that following the natural development sequence works best. The assessors find:

Requirements and testing are strong: requirements are reviewed, and tests trace to requirements.
Risk management is weak: hazards are discussed informally but there is no risk management file, and no trace from risk controls to software requirements.
SOUP is not identified as such; the maths library is in the build but nobody has recorded its known anomalies or limitations.
Configuration management covers source code but not requirements, test records or tool versions.
There is no defined problem resolution process; bugs are fixed without analysing their effect on safety.

Step 3 – Interpret the profile

The assessors rate software risk management at Level 0, because its outcomes are only partly achieved. Configuration management reaches Level 1, but because requirements, test records and tool versions are not controlled, PA 1.1 is only Largely achieved, so it cannot reach Level 2 even though planning and monitoring exist. Requirements analysis and system testing reach Level 2. Compared with the target profile, the gaps are risk management, configuration management and SOUP handling within architectural design. The coverage view also shows that several Class C outcomes of IEC 62304, such as detailed design and unit verification evidence, are thin.

Step 4 – Improve

Together with the assessors, Brightwater writes an improvement plan that ranks actions by their effect on safety and on the target profile:

Introduce a risk management procedure aligned with ISO 14971 and create a risk management file for the module, linking each software-related hazard cause to a risk control and to a verifying test.
Add a SOUP register listing each external component, its version, its intended use and its known anomalies.
Extend configuration management to requirements, test records, build tools and SOUP versions, with baselines at each release.
Define a problem resolution process that records, investigates and assesses the safety impact of each problem, and trends problems over time.
Deepen detailed design and unit verification for the Class C items.

Step 5 – The customer assessment

Five months later the manufacturer's own assessment team, led by a qualified lead assessor, performs the formal assessment against the agreed target profile. Risk management now reaches Level 1: the new risk management file is not yet complete for every hazard, so PA 1.1 is rated Largely achieved, and that alone keeps the process below Level 2 although planning and monitoring have started. Configuration management reaches Level 2. One gap remains in problem resolution trending. The manufacturer awards the contract with a condition that Brightwater closes that gap before the first release, and the two companies agree to reassess after a year.

What the example shows

The assessment did not certify anything. It gave the customer a fact-based picture of supplier risk, gave Brightwater a precise improvement list tied to IEC 62304 and ISO 14971, and created a shared language for follow-up. Note also that the first-party assessment found the biggest issues, which were all about medical device specifics: risk management, SOUP and safety-driven problem handling. That pattern is typical for capable software firms entering the medical device domain.

Lesson 7 – Relationship to other standards and frameworks

MDevSPICE sits at the crossing point of two families: the SPICE family of process assessment standards and the family of medical device standards. Knowing the neighbours helps you explain what MDevSPICE adds and what it does not replace.

Standard or framework	Owner	What it is	Relationship to MDevSPICE
IEC 62304	IEC (with ISO)	Requirements for medical device software life cycle processes, scaled by safety class	The foundation and always in scope; MDevSPICE outcomes derived from it carry their safety classes
IEC TR 80002-3	IEC	Technical report giving a process reference model of the IEC 62304 processes	Starting point of the MDevSPICE reference model, written by the same research group
ISO 13485	ISO	Quality management system requirements for medical device organisations; certifiable	Its design and development and management requirements are folded in as outcomes, notes or Level 2 generic practices
ISO 14971	ISO	Risk management process for medical devices	Concentrated in the software risk management process, with an annex mapping per life cycle process
ISO/IEC 15504 and ISO/IEC 330xx	ISO/IEC JTC 1/SC 7	Generic requirements and models for process assessment	Supply the two-dimensional structure, capability levels and rating scale; 330xx is the current successor
Automotive SPICE	VDA QMC	Domain-specific SPICE assessment model for automotive electronics and software	A sister domain model and an inspiration; similar structure for a different regulatory world
VDI 5702 Medical SPICE	VDI (Germany)	A separate process assessment model for medical device software, current edition 2026-01	Independent model with a similar aim; not the same as MDevSPICE
CMMI	ISACA CMMI Institute	Generic capability and maturity model with appraisal method	Generic best practice without built-in medical device requirements

MDevSPICE and IEC 62304

IEC 62304 tells you which processes and activities are required for each safety class. It does not tell you how well managed those processes are, and it gives no rating scale. MDevSPICE uses IEC 62304 as its compliance floor and adds the capability dimension above it, plus generic software engineering practices from ISO/IEC 12207 and 15504-5. When IEC publishes the second edition of IEC 62304, which is still being drafted, MDevSPICE users will need to check which outcomes change.

MDevSPICE and ISO 13485

ISO 13485 is the quality management system standard for the whole organisation and is the usual basis for certification by a third party and, since February 2026, for the FDA's quality management system regulation. It says little about how software should be engineered. MDevSPICE reaches into ISO 13485 only where it touches design and development and process management, so it complements but never replaces a quality system audit.

MDevSPICE and the SPICE family

Anyone who knows Automotive SPICE will feel at home: process groups, purposes and outcomes, base practices, work products, capability levels and N-P-L-F ratings all work the same way. Two differences stand out. MDevSPICE treats some work products as normative because regulators require them, and it keeps lineage tags so each requirement can be traced to its source standard. Because MDevSPICE was built on ISO/IEC 15504, users who need conformity with the current ISO/IEC 330xx documents should check the measurement framework and assessment process against ISO/IEC 33020 and ISO/IEC 33002.

MDevSPICE and other medical SPICE models

Germany's VDI publishes its own Medical SPICE process assessment model as VDI 5702 Part 1, whose current edition (January 2026) replaced the 2017 edition. The names are similar but the documents and owners are different. When a customer asks for a "medical SPICE" assessment, confirm which model is meant.

Common pitfalls and best practices

Pitfalls

Presenting an MDevSPICE result as certification to IEC 62304 or ISO 13485; it is an assessment, not a conformity certificate, and regulators are not bound by it.
Rating from procedures alone; a written process that nobody follows does not achieve its outcomes, so evidence must come from real projects and interviews.
Leaving software risk management out of scope without adding its annexed requirements to the processes that are assessed, which hides the most important safety gaps.
Applying the model's original source editions blindly; ISO 13485, ISO 14971, IEC 62366 and the EU and US regulations have all changed since the model was built, so map findings to current editions.
Ignoring the software safety class during scoping, which leads to demanding Class C detail from Class A software or missing Class C requirements altogether.
Chasing high capability levels on every process instead of the levels that the business and the risk actually need.
Treating SOUP as ordinary code and never recording its versions, limitations and known anomalies.

Best practices

Agree the purpose, sponsor, scope, standards and target profile in writing before any interviews take place.
Start with a lightweight assessment of the core IEC 62304 processes to find the largest gaps quickly, then extend the scope.
Follow the natural order of the development life cycle in interviews, and use a scripted question set so that every scoped standard is covered.
Present findings both as capability profiles and as coverage per standard; teams act faster when they see both views.
Prioritise improvement actions by patient safety impact first, then by gaps against the target profile.
Keep traceability from system requirements through software requirements, risk controls and tests; it supports almost every process in the model.
Plan a reassessment after the improvement plan to confirm progress and keep the cycle going.

Summary and key takeaways

MDevSPICE is a SPICE-based assessment framework for medical device software, created at the RSRC in Dundalk, Ireland; it is not an ISO or IEC standard.
It combines compliance with medical device standards and the capability view of SPICE in a single assessment.
IEC 62304, through IEC TR 80002-3, is the foundation and always in scope; ISO 13485, ISO 14971, usability, product safety standards and FDA guidance are integrated and can be scoped in or out.
The published model has 23 processes in three groups: system life cycle, software life cycle and support.
Each process has a purpose and normative outcomes, informative base practices and work products, some of which are normative because regulators require them.
Processes are rated with process attributes on the N-P-L-F scale and placed on capability levels 0 to 5.
MDevSPICE-Adept offers a lightweight, two-day, improvement-focused version of the assessment.
Results support audit readiness, improvement and supplier selection, but they do not certify compliance and must be mapped to current editions of the standards.

Reflection questions

Your company has passed its last notified body audit. What would an MDevSPICE assessment tell you that the audit report did not, and who in your company would care?
For a product you know, which software safety class would apply, and how would that class change the scope and the target profile of an assessment?
Choose three of the 11 default MDevSPICE-Adept processes. What evidence would you show an assessor for each, and where is it weakest today?
A manufacturer wants every supplier at Level 3 for every process. How would you argue for a more selective target profile, and what risks would you weigh?
Several standards behind MDevSPICE have new editions. How would you organise a mapping so that assessment findings stay useful for today's audits?