IEC 62304 – Part 3: How agile are you?
In this third part of our four-part series (Part 1: Its a class app and Part 2: Its a different class) on the up and coming IEC/DIS 62304 we look at the relationship between the standard and the world of agile software development. The forthcoming version of the standard maintains the same approach to the topic of live-cycle models.
Lifecycle Development
Annex B of 62304 introduces the subject of different lifecycle models and how they may relate to the standard but there is understandably no direction given on the route you choose, that is for you as a team or company to decide. Figure 1 shows an amended version of what is in Annex B:
| Development strategy | Define all requirements first? | Multiple development cycles? | Distribute interim software? |
|---|---|---|---|
| Waterfall (once-through) | Yes | No | No |
| Incremental (pre-planned product improvement) | Yes | Yes | Maybe |
| Evolutionary (user need not complete not all requirement up front) | No | Yes | Yes |
| The reality • with good usability engineering | No | Yes | Yes |
Figure 1: Development life cycles
We have mentioned usability engineering in Figure 1 as this is ultimately the most agile of activities in the medical device sector. Carried out as early in the development process as possible and formative evaluations carried out multiple times. This is a really agile process of both defining and enhancing requirements.
IEC 62304 principles:
62304 closes the topic in Annex B by giving 3 principles that need to be met regardless of life-cycle:
a) all process outputs should be maintained in a consistent state
b) all process outputs should be available when needed as input to further work
c) before release all outputs are consistent and all dependencies should be observed
Typical medical agile process
The figure below shows a typical agile process flow in 62304 projects:
Ultimately as shown in Figure 2 we are looking at the key concepts of 62304, 14971 and 13485, risk management, design output matching design input, design reviewing, change management and configuration management. Iteration around the backlog in sprints helps speed the process but ensuring all requirements have been met before release.
More guidance in AAMI TIR45
As an organisation we are big fans of the Association for the Advancement of Medical Instrumentation (AAMI) documents and AAMI TIR45 is a key technical information report for any teams looking to use agile methodologies in the medical sector. TIR 45 challenges in a balanced manner the agile principles so they can be appropriately applied to medical device software development e.g. ‘saying we are agile and we don’t need design documentation is not a defendable position in the medical device software world’ countering this by supporting the intent of the value from the manifesto.
It would be huge help if some of the discussions in TIR45 could be added as an annex in 62304 to give more guidance to teams wanting to use agile but at the same time fulfilling all the requirements of 62304.
In the last part of this blog series we will look at the rapidly changing world of cybersecurity and how it is addressed in IEC/DIS 62304.
By Alastair Walker, Consultant
Do you want to learn more about the implementation of IEC 62304, ISO 14971 or any other standard in the Automotive or Medical Device sector? We work remotely with you. Please contact us at info@lorit-consultancy.com for bespoke consultancy or join one of our upcoming online courses.
