The Medical Device Regulation (MDR) (like the Medical Device Directive (MDD) and thus the Medical Device Act before it) requires manufacturers to comply with life cycle processes for their software. IEC 62304 and IEC 82304 also refer to software life cycle processes. But what is a software life cycle?
The software life cycle includes all phases a software device goes through, from the initial idea to decommissioning.
It is, therefore, not just about software development:
IEC 62304, on the other hand, defines the term software life cycle model as a conceptual structure spanning the life of the software from definition of its requirements to its release, which:
- identifies the PROCESSES, ACTIVITIES, and TASKS involved in development of MEDICAL DEVICE SOFTWARE,
- describes the sequence of and dependency between ACTIVITIES and TASKS, and
- identifies the milestones at which the completeness of specified DELIVERABLES is verified.
In its definition, IEC 62304 thus limits the term software life cycle to the first phase, software development, although the standard also defines requirements for other processes (see below).
IEC 82304 addresses the whole life cycle including post-market activities like maintenance, decommissioning, and disposal of the software.
Phase 1: Software development
Many process models are known and used for software development. These include the waterfall model, the V-model, agile process models, and the Rational Unified Process.
IEC 62304 does not prescribe a specific software life cycle model. It considers agile process models to be adequate, even if it seems to be more closely aligned with a V-model (at least as a documentation model). Regardless of which process model a manufacturer uses for the development of its software, the documentation must contain the usual artifacts at the end of the software development:
- software requirements
- software architecture and detailed design
- code and other artifacts
- code reviews, outputs of static code analysis
- unit tests, integration tests, and system tests, each with test specification and test results
Phase 2: Software maintenance
Most errors reported in error databases (e.g., by the BfArM or the FDA) do not concern the initial software development but the next phase in the software life cycle, the maintenance.
According to the FDA, 79% of all errors are caused in the maintenance phase. Accordingly, standards such as IEC 62304 or the FDA’s guidance documents require that there are also defined process models for maintenance.
Put simply, software maintenance should go through the same phases as initial software development. Ideally, the tests can be run as regression tests to ensure that as few new bugs as possible are added during the maintenance phase.
Phase 3: Decommissioning
The last phase that software goes through during its life cycle is decommissioning. This is often done by replacing it with another device.
Other processes in the life cycle
IEC 62304 includes other processes in the software life cycle, such as the risk management process, the problem resolution process, and configuration management. We see the problem resolution process as an integral part of software development and maintenance. This process ensures that errors are analyzed, trends are evaluated, and the appropriate measures (correction, reporting to authorities, etc.) are taken. The configuration management process is designed to ensure that no unauthorized changes are made to the code (customers cannot call the developer directly) and that it is possible to trace which artefacts in which version are part of a software release at any time.
Change history
- 2024-01-22: References to IEC 82304 added
- 2015-05-02: Article initially published
