Medical device software development: a practical overview
How medical device software development works under IEC 62304: safety classification, the life-cycle activities, the deliverables to plan for, and why traceability runs through all of it.
The standards that apply
Medical device software development is governed primarily by IEC 62304, which defines the software life-cycle processes. It does not stand alone: it sits inside a quality management system such as ISO 13485, and it is tied to risk management under ISO 14971. Together they expect a disciplined, documented, traceable development process.
Safety classification sets the rigour
IEC 62304 assigns each software system, and optionally each software item, a safety class of A, B, or C, based on the harm possible if the software fails. Class C, where death or serious injury is possible, requires the most detailed design and verification. Classification is the lever that scales how much rigour and documentation the standard expects.
Life-cycle activities
- Software development planning.
- Software requirements analysis.
- Architectural and detailed design.
- Implementation and unit verification.
- Integration and system testing.
- Release, with known anomalies evaluated.
- Ongoing risk, configuration, and problem management.
Traceability ties it together
Across all of that, the standards expect a traceable path from software requirements to architecture, implementation, and verification, with risk controls traced as well. Keeping that path accurate as the software changes is the practical challenge. See the IEC 62304 guide, the IEC 62304 checklist, and how Traceable supports medical device teams.
This guide is educational and does not certify any product or organisation.
Common questions
What standard governs medical device software development?
IEC 62304 defines the software life-cycle processes for medical device software, and it sits within a quality management system such as ISO 13485, with risk management per ISO 14971.
What is software safety classification?
IEC 62304 assigns a safety class of A, B, or C based on the possible harm if the software fails. Higher classes require more detailed design, verification, and documentation.
Why is traceability central to medical device software?
The standards expect a traceable path from software requirements through architecture and implementation to verification, with risk controls traced too. Maintaining that path by hand is where teams lose time and coverage.
Keep your software traceability live
See requirements, architecture, and verification traced in one place.