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 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 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 the 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 a 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.
PEMS life cycle model according to IEC 60601-1

Fig. 1: PEMS life cycle model according to IEC 60601-1: software development life cycle in red, system development life cycle in green (Click to enlarge)

Unfortunately, IEC-60601’s PEMS life model is rather misleading and inconsistent. The following chart is more concise.

Medical device life cycle model

Fig. 2: Typical life cycle activities throughout software development. This figure can be used as a documentation model rather than a life cycle model (Click to enlarge)

Development Processes and Process Models

a) What 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
Modeling 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 model.

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 shifting 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 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.