ISO 13485 · Expert · 14 min lesson
IEC 62304 software lifecycle, safety classes and development planning
IEC 62304:2006 with Amendment 1:2015, clauses 4.1 to 4.3, 5.1 to 5.3, 7.1 and 8.1; ISO 13485:2016 clauses 4.1.6 and 7.3
What you will learn
- Explain how IEC 62304 organises software lifecycle processes and how it connects to ISO 13485 clause 7.3 and ISO 14971.
- Assign a software safety class A, B or C under clause 4.3 of Amendment 1 and justify the decision, including segregation of items.
- Write a development plan under clause 5.1 that covers verification, risk, configuration management, SOUP and traceability, and spot a plan that fails.
Key takeaways
- IEC 62304:2006+A1:2015 is the current edition; a second edition is in development and does not yet replace it.
- The standard defines processes: development (5), maintenance (6), risk (7), configuration (8) and problem resolution (9).
- Class A, B or C under clause 4.3 rests on the harm a software failure could contribute to, with failure probability assumed to be 100 percent.
- Segregated items may take a lower class only when the architecture documents and justifies the segregation.
- The development plan (5.1) is written first, kept updated, and covers verification, risk, configuration, SOUP and traceability.
Free practice question
Halden adds a reminder app that only sends a notification when a patient forgets to log a meal. A failure can at worst mean a missed reminder, and the patient still has the paper diary. A developer says every Halden software is Class C by company policy.
What does clause 4.3 require for classifying this reminder app?
Classify from the possible harm of its failure; with no path to injury it can be Class A, and the reasoning must be recorded.
Correct. Clause 4.3 bases the class on possible harm, so a reminder with no injury path can be Class A with documented reasoning.
Apply Class C to all products because a single company policy overrides clause 4.3.
Not quite. Clause 4.3 requires the class to follow the harm of each software system, so a blanket policy cannot replace the assessment.
Use Class B because it is the safest middle choice.
Not quite. Clause 4.3 gives no middle default; the class must follow the assessed harm, and a guess is not a justification.
Skip classification because the app is not a medical device.
Not quite. If the reminder is part of the device or system, clause 4.3 applies and the manufacturer must still classify it.
Key terms
- software safety class: The category A, B or C assigned under clause 4.3 from the possible harm that failure of the software could contribute to.
- SOUP: Software of unknown provenance: software item already developed and generally available that was not developed for this device or lacks adequate development records.
- software item: Any identifiable part of a software system, which may be made of software units.
- software unit: A software item that is not subdivided into other items, such as a function or class.
- development plan: The clause 5.1 record that defines processes, deliverables, traceability, verification, risk, configuration management and responsibilities.
- segregation: Architectural separation that shows a failure of a lower class item cannot lead to failure of a higher class item (clause 5.3.5).
- traceability: The documented link between system requirements, software requirements, design, tests and risk control measures.
- configuration item: A uniquely identified and controlled element of the software, including SOUP and supporting items (clause 8.1).
Official sources
- IEC 62304:2006 Medical device software - Software life cycle processes (with Amendment 1:2015), ISO catalogue entry
- ISO 13485:2016 Medical devices - Quality management systems - Requirements for regulatory purposes
Go further
The full lesson has narrated slides, more scenario questions with explained answers and a simulation.
Open the AcademyWatch on YouTubeIllustrative example. Educational only, not legal advice.