AI in medical devices · Medium · 13 min lesson

AI development lifecycle: requirements, model design and IEC 62304 alignment

IEC 62304:2006+A1:2015 clauses 4.3, 5 and 8, MDR Annex I section 17.2, EU AI Act Articles 9 and 11, GMLP principles 4 and 6

What you will learn

Map the stages of an AI development lifecycle onto IEC 62304 processes and say where the standard needs adapting for learned components.
Write measurable model requirements and justify a software safety class from harm and real risk controls.
Keep design, third party, training, testing and release records that trace a requirement to a rebuildable released model.

Key takeaways

IEC 62304 gives the lifecycle process backbone; it does not mention machine learning, so each activity is adapted and the mapping is documented.
The software safety class follows possible harm and real risk controls, and the justification is reviewed when the model changes (clause 4.3).
A model requirement states metric, population, threshold, operating point and subgroup floors, and can fail a test (clause 5.2).
Pretrained models and frameworks are SOUP items: identify them, state requirements and assess limitations (clauses 5.3.3, 8.1.2).
Keep independent test data, full run logs and a release baseline that lets you rebuild the exact model (clauses 5.7, 5.8).

Free practice question

Halden's plan for the Rhythma arrhythmia model says: 'IEC 62304 does not mention machine learning, so it does not apply to us; we follow our data science practices.' The product is a Class IIa device in the EU.

What is the best assessment of this statement?

Correct, because a standard that does not name machine learning cannot be applied.

Not quite. The standard is a process framework, and MDR Annex I section 17.2 expects a lifecycle, risk management and verification regardless of technique.

Incorrect: the standard is process based, so the activities are applied and adapted to learned components, with the mapping documented.

Correct. IEC 62304 clauses 5 to 9 describe processes that fit learned software, and MDR Annex I section 17.2 expects a documented lifecycle.

Correct, but only for neural networks and not for simpler models.

Not quite. The process framework does not distinguish model types; clause 5 applies to software whatever its internal technique.

Incorrect, because the standard requires a specific neural network architecture.

Not quite. IEC 62304 prescribes processes and records and never prescribes an architecture or algorithm for a software item.

Key terms

IEC 62304: International standard for medical device software lifecycle processes; amended in 2015 and used as a harmonised route to MDR software requirements.
software safety class: Class A, B or C assigned from the harm a software failure could contribute to, which sets the rigour of the process (clause 4.3).
SOUP: Software of unknown provenance: an item not developed under the standard, such as a library or pretrained network.
operating point: The fixed decision threshold at which sensitivity and specificity are claimed; it is set in the requirement, not tuned afterwards.
locked test set: Data kept independent of training and tuning, used once per release candidate against predefined acceptance criteria.
release baseline: The identified set of code, data versions, model file, configuration and documents that define a release.
GMLP: Ten guiding principles for good machine learning practice in medical devices, published jointly by regulators; guidance, not law.
traceability: A recorded link from a need through requirement, design, test and release evidence.

Official sources

Go further

The full lesson has narrated slides, more scenario questions with explained answers and a simulation.

Open the Academy Watch on YouTube

Illustrative example. Educational only, not legal advice.