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
Study guide · Updated · About 8 minutes reading + 20–30 minutes practice
Before you start: Read TEA-107 and TEA-109. Understand the device’s intended use and risk process before applying software lifecycle requirements.
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.
Define the software system before classifying it
IEC 62304 concerns lifecycle processes for medical-device software, including software within a device. Its A, B and C software safety classes guide applicable lifecycle activities; they are distinct from regulatory device classes and from SIL or ASIL. Determine classification using the standard’s actual rules and the device risk analysis.
Identify the software systems and items, including controller firmware, an application computer, boot or update software and relevant dependencies. Do not assume a second executable creates an independent risk-control boundary. Any credited external control or segregation needs a supported rationale in the real architecture.
As an engineering exercise, trace one hazardous behaviour from the device risk record to software contributions and controls. Ask which software can initiate, fail to detect or fail to respond to it. This produces a more useful classification discussion than choosing a class from code size or programming language.
Connect lifecycle work products into a continuous record
A plan says how work will be controlled; requirements define expected behaviour; architecture and design allocate it; verification provides evidence; problem resolution and configuration management keep the record coherent. Documents with matching titles are insufficient if they refer to different software boundaries or versions.
Manage software of unknown provenance, commonly abbreviated SOUP, in the applicable lifecycle context. Identify the actual component and version, its required behaviour, known anomalies and the evidence needed for its use. An open-source licence or a supplier’s popularity does not establish suitability for the intended medical function.
Plan unit, integration and software-system verification with the activities applicable to the chosen classification. Keep device-level validation and broader product obligations visible alongside the software lifecycle. Passing software tests does not, by itself, establish that the complete device meets user needs.
| Evidence link | Question to resolve |
|---|---|
| Risk → software requirement | Which behaviour implements or supports the control? |
| Requirement → architecture | Which item owns the behaviour and its interfaces? |
| Architecture → verification | Which evidence establishes timing, segregation and failure response? |
| Release → configuration | Which binary, dependency and configuration were tested? |
| Problem → maintenance | Which released products are affected and how is closure verified? |
Treat maintenance as continued controlled development
A patch or component update can affect safety classification rationale, interfaces, timing and risk controls. Perform an impact assessment that drives the verification scope and documentation changes. A small code diff can have a large behavioural effect when it changes scheduling or a shared library.
Before release, reconcile open anomalies with their product impact and authorised disposition. Record the supported software and hardware combination and the installation or recovery behaviour. Keep cybersecurity response coordinated with this lifecycle so urgent remediation remains identifiable, reviewable and verifiable.
Practical exercise
An illustrative engineering exercise; values are assumptions for this lesson.
Assess a logging change on an analyser controller
A proposed maintenance release writes diagnostic records to flash synchronously. The same task supervises a temperature-control timeout.
- Identify the safety-related behaviour potentially affected by the logging change.
- List the impact-analysis and verification evidence required.
- Explain why calling the change “diagnostics only” is insufficient.
Show the worked answer
Synchronous flash operations may extend the supervision interval and delay a protective response. Review execution and blocking time, flash error handling, resource contention and the state during power interruption. Trace the effect to the temperature-control requirements and related risk controls.
Verify the released configuration under logging bursts, flash-busy conditions and relevant faults. Update the architecture or timing evidence where assumptions change, and document anomaly disposition. The label “diagnostics” describes the feature’s purpose but does not establish its lack of influence on safety-related behaviour. Classification and activity decisions follow the actual software system and risk rationale.
Review criteria
- Impact follows shared execution and resources.
- Verification challenges the affected risk control.
- The release record identifies the exact changed configuration.
Check your understanding
Is Class C the same as a Class III medical device?
No. IEC 62304 software safety classification and regulatory device classification serve different purposes and use different rules.
Does a software verification report replace device validation?
No. Software verification and complete-device validation answer different questions and must be coordinated.
Further learning
- IEC 62304:2006 + AMD1:2015 — official consolidated publicationPublisher source supporting this module’s framework discussion.
- 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.