Software in Medical Devices, by MD101 Consulting

Agile development process

Agile methods are becoming the state-of-the-art of software development. Most of mobile Apps developed today are developed with agile methods. Agile methods allow to release multiple versions of software at a high pace. A heavy trend in mobile platforms, where it's very common to have multiple updates of Apps available on apps stores.
Unfortunately, this is not the case in the medical devices industry. The habit is to have a slower pace of releases (e.g. once every year), compatible with the high level of safety required for most of medical software.
Agile methods are known to be hard to implement, when regulations demand a high level of formalism. The goals of agile methods are even seen in contradiction with the goals of regulations.

Safety level of Apps

There is today a profusion of mobile medical Apps. But most these Apps are intended to be used in less hazardous situations than software use in clinical settings. For example:

• Every medical device manufacturer is pushed by the marketing to release a very pretty App that will be a software companion to their (brick and mortar) medical device products. For instance, to be able to present a simple view of the medical device state from a remote location.
  
• There are many new Apps released by start-ups, which have an intended use that may be considered medical. Such apps are in a grey area where apps are either general health apps (without clinical outcome), or real medical devices with a clinical outcome. See the last post about the response of the FDA on such apps.
  

I'm going to excess. There are a lot of mobile apps, which are real medical devices with a real clinical outcome. Especially those designed for home-use, for patients with chronic diseases.
But the trend is here. There are a lot of mobile apps intended to be used in low or non hazardous situations.
For all these apps, agile methods are easier to implement, as the level of scrutiny on the software development process, demanded by regulation authorities, is lower than the one for most of "classical" medical software.

Thus, this is relevant to apply agile methods to mobile apps development. Firstly because mobile apps are usually present low risks, secondly because that's the state-of-the-art of mobile app development.

Agile and IEC 62304

IEC 62304 is actually THE standard for software development and maintenance. It contains all the requirements to apply to software development and maintenance processes.
The requirements in IEC 62304 are presented in a waterfall-like manner. It's easier to apply the standard with a waterfall process, given the way the standard presents the requirements.
However, the standard doesn't impose a development process style. It can be a waterfall process, an iterative process, or full agile process. But it's more difficult to apply the standard when developing with agile methods.
Fortunately, the standard is less stringent with software with low risks. It defines 3 classes (see the standard text body for the full definition of classes):

• Class A: no risk, a few requirements of the standard are applicable, with medium formalism,
• Class B: medium risk, most of requirements are applicable, high formalism,
• Class C: high risk, high formalism.

Remark 1: I set formalism to medium or high, compared to the usual (absence of) formalism of agile methods.
Remark 2: no formalism doesn't mean no planning or no management.

So, given the following situation:

• Most of apps are low risk, probably in class A,
• Agile methods are the state-of-the-art,
• IEC 62304 is light for class A software,

We can conclude:

• Agile methods are recommended for the development of such mobile apps,
• By chance, IEC 62304 allows a minimal formalism for low risk apps, compatible with the pace of agile methods.

Remark 3 (for experts :-)): the following reasoning "a mobile app of class A means no risk. So this is not a medical device" is not true. No risk doesn't mean no clinical outcome. Regulations authorities may impose the medical device regulation, to confirm by post-market surveillance that there is actually no risk.

For higher classes

As we said, there are also many apps of higher classes, which have a well-established clinical outcome and, other side of the medal, represent a medium or high risk.
While waterfall is the classical process for hazardous software, the trend of the market is so heavy that every manufacturer wants to or plans to apply agile methods. This is possible, but with a higher learning curve than for low risk software.
A possible way of implementing agile methods is:

1. To switch to an agile method with a new project, in the phase of feasibility or prototyping, without the overhead of the IEC 62304,
2. To adapt the agile method to the constraints of IEC 62304, when industrializing the software product.

The constraints of IEC 62304 on agile methods are important and may require to tweak the agile process, as I already explained in this article about agile methods in regulated environment.

But, from a more general point of view, agile methods allow medical devices manufacturer to follow the pace of evolutions in the world of mobile apps. Thus avoiding falling behind competitors.
A massive trend is here, let's switch to IEC 62304 with agile methods!


In the next article, we'll talk about wireless connections.