IEC 62304 — Medical-device software lifecycle
Understand the lifecycle processes used to develop and maintain medical-device software, from planning and architecture to problem resolution and change.
After this module, you should be able to:
- Explain the purpose and scope of IEC 62304
- Relate software safety classification to process rigour
- Identify core development and maintenance activities
- Connect risk controls, SOUP and traceability to evidence
IEC 62304 controls the software lifecycle; it does not define the whole medical device.
IEC 62304 provides processes, activities and tasks for medical-device software development and maintenance. It is used alongside device-level risk management, quality management, usability, product safety and regulatory requirements.
Software safety classification—A, B or C—scales specified lifecycle activities according to the harm that could result from a software failure, considering external risk-control measures where applicable. Classification must be reasoned from the device risk analysis, not chosen from product reputation.
Translate the framework into controlled engineering work.
| Area | Question | Typical evidence |
|---|---|---|
| Planning | How will lifecycle activities, tools, configuration and problem resolution be controlled? | Software development plan |
| Requirements | What must software do, including risk controls and interfaces? | Software requirements specification |
| Architecture and design | How are items, segregation, interfaces and SOUP structured? | Architecture and detailed design evidence |
| Implementation and verification | How are units, integrations and the software system verified? | Reviews, analyses and test results |
| Maintenance | How are problems, changes and releases assessed and controlled? | Maintenance and problem-resolution records |
Apply the current controlled source
This module is an orientation. Confirm the applicable edition, amendments, adopted regional version, contractual commitments and sector-specific interpretations before defining compliance.
Use a risk-based application sequence.
- 1. Define the software system, boundaries, items and release model
- 2. Establish the safety classification and document its rationale
- 3. Plan development, configuration, risk-management support and problem resolution
- 4. Trace system needs and risk controls into testable software requirements
- 5. Define architecture, segregation, interfaces and SOUP controls
- 6. Verify units, integrations and system requirements; retain anomalies and release evidence
Worked application: infusion-rate control
A device risk control limits programmed delivery and detects motor or sensor faults. The software requirements specify limits, units, timing and responses. Architecture separates user input, therapy control and monitoring. Tests trace boundary values and injected faults back to the risk-control requirements.
Build evidence that explains the reasoning.
Lifecycle model, standards, tools, roles and deliverables.
Class and rationale based on possible harm.
Functional, interface, performance and risk-control requirements.
Items, interfaces, segregation, SOUP and data/control flow.
Protocols, results, anomalies and traceability.
Configuration, unresolved anomalies and approval.
Common failure patterns
Templates exist but do not reflect actual engineering work.
Class is selected without a device-risk rationale.
Third-party software lacks requirements, risk and anomaly evaluation.
Results cannot show which requirement and build were verified.
Further learning
- IEC 62304 consolidated editionOfficial IEC catalogue entry for the medical-device software lifecycle standard.
- TEA-107 · Embedded software architectureComponents, states, interfaces and verifiable structure.
Use the standard to strengthen decisions, not decorate them.
Make scope, tailoring, responsibilities, technical reasoning and objective evidence explicit—and always work from the current authorised text.