Software Life Cycle Processes for Medical Devices
1. Overview on software life cycle processes
The software life cycle covers all activities from the first product idea to deinstallation, respectively decommissioning of the last instance of the product. The software life cycle processes include but are not limited to
- Software development
- Software installation and operation
- Software maintenance
- Problem resolution
- Deinstallation / decommissioning
2. Regulatory requirements
As software testing cannot prove the correctness of software, software errors (bugs, usability problems) have to be avoided right from the beginning by following software life cycle processes. All software related regulations such as IEC 62304 and the FDA software validation guidance document demand from medical device manufacturers to follow these life cycle processes. However, they do not enforce a particular life cycle model such as a waterfall model, v-model or an agile development processes.
a) IEC 62304
Life Cycle Processes
IEC 62304 requires the following processes to be implemented
- Software development
- Software maintenance
- Problem resolution
- Risk management
- Configuration management
Development Process
The software development process must cover - depending on the software safety class - the following activities:
- Creation of a software development plan (see below)
- Specification of the software requirements
- Development of a software architecture and a detailed design
- Implementation of the code e.g. following coding guidelines
- Verification of the code e.g. by code reviews and software tests such as unit tests, integration tests and system tests
- Release of the software
b) Medical Device Regulation (MDR) and Medical Device Directive (MDD)
The medical devices regulation (MDR) and medical device directive (MDD) require software lifecycle processes:
"For devices that incorporate software or for software that are devices in themselves, the software shall be developed and manufactured in accordance with the state of the art taking into account the principles of development life cycle, risk management, including information security, verification and validation."
Manufacturers prove compliance with these requirements by following the IEC 62304.
c) Other regulations
All relevant regulations and standards require a process-oriented approach:
- The ISO 13485 calls for process-oriented approach, not just in the development.
- The ISO 14971 describes a risk management process.
- The IEC 62366 demands, that the usability of medical devices using a "usability-oriented development process" be followed.
- The IEC 60601-1 obliges manufacturers of programable electrical medical systems (PEMS) to follow a life cycle process. The appendix contains this example that has a lot of similarities with the v-model.
Unfortunately, IEC-60601's PEMS life model is rather misleading and inconsistent. The following chart is more concise.
Development Processes and Process Models
a) What a process defines
The development process describes as any other process
- who (which role e.g. requirements engineers, programmers, software architects, testers, etc.)
- transfers: which inputs to which outputs (documents, products, decision, components)
- in which sequence (e.g. in parallel, sequential)
- how (i.e. using which methods, procedures and tools)
b) Typical life cycle activities
The typical activities throughout a development process include
- defining an intended use and making a business case
- identifying the stakeholder requirements
- specifying system respectively software requirements and reviewing this "SRS"
- designing a technical solution e.g. creating a system respectively software architecture including review
- implementing, developing, programming system respectively software components accordingly following best practices e.g. coding guidelines
- verifying components e.g. with unit tests or code reviews
- verifying the integration of components e.g. integration tests
- verifying the entire system respectively software e.g. software tests
- validating the entire system respectively software e.g. summative usability evaluation or clinical evaluation
To prove that these activities actually have been performed, manufacturers respectively developers have to plan, document and verify what they do.
c) Methods and procedures
For each of these activities manufacturers have to define a set of methods or procedures (set of methods).
| Activity | Method(s) (Examples) |
|---|---|
| Identify stakeholder requirements | Context methods (as described in ISO 9241) |
| Specify software requirements | Prototyping with mock-up screens |
| Modelling software architecture | UML modeling, implementation of vertical prototypes |
| Software testing | Blackbox test methods e.g. with equivalence classes |
d) Process models
It is up to the manufacturers to define the sequence of these activities and to determine whether these have to be performed in a linear or in an iterative and incremental approach.
Accordingly, most medical device manufacturers follow
- a waterfall
- V-model-like
- an agile process mode.
You can read the Agile Software Development more here.
Software Development Process Versus Software Development Plan
Manufacturers are free to define life cycle processes specifically for each of their products. For example, they can pick an agile development process to develop one product and define a waterfall model for another.
a) Content of development plan
The product respectively project specific decisions are documented in a (software) development plan. In this plan they can determine
- the processes to be applied for the specific project
- the roles and the assignation of specific persons to these roles
- the methods and procedures
- the tools
- the milestones
b) Distribution of content
If the development team has to follow always the same requirements, Johner Institute recommends to shift as many of these requirements into the development process description (SOP) and to keep the development plan rather slim.
However, if the development team, e.g. an engineering service provider, has heterogenous projects then the SOP will be rather generic and require to describe the specific requirements in a project specific development plan.
However, this figure implies no V-model - even if it looks like it. These activities can also be run through interactively and incrementally. Read more here about agile (software) development.
Note, that you must complete all the activities on the left side with a verification.
Author:
Prof. Dr. Christian Johner
Back To Top
Privacy settings
We use cookies on our website. Some of them are essential, while others help us improve this website and your experience.