By Martin Bakal, WW Offering Manager - Electronics Industry, IBM
For a decade or more, software teams have benefited from agile development methods where solutions evolve through collaboration between cross-functional teams with frequent testing. Traditional, non-agile approaches typically rely on a more regimented style of development. In these regimented approaches, testing and integration are regarded as late-stage activities, so problems are frequently discovered late, which makes products late with an added expense of fixing the issues. In medical device development the advantage of traditional approaches is to allow requirements to be developed up front, which helps regulatory agencies sign off before development is done. This article will discuss how medical device companies can use new techniques to do agile development and still meet regulatory needs.
In order to understand how to meet regulatory needs you have to first understand what the regulators are looking for. The FDA and other regulatory agencies fundamentally want to see that your product has safety in mind. To do so they require complete traceability through the hardware and software. There is even a fairly new standard, IEC 62304, adopted worldwide that is wholly focused on software traceability from requirements through architecture to tests. These requirements and others mean we need traceability and reporting we typically only see in heavy-weight processes like waterfall.
Medical devices companies are going agile primarily because they need to respond to customer needs and get feedback quickly. Agile builds this into the process by focusing on building one feature or story at a time and then showing it to stakeholders (marketing team, customers, etc). This works well when updating an application that goes on a webpage. But how can you achieve this when building a physical device that has a long regulatory process for each release?
One way to do this is to still release in your normal cycle but show customers the individual updates of webinars and other types of media after each story is complete. Via these frequent updates customers can give you feedback more quickly. The fact is you can’t just make the release cycle more frequent since it includes giving tests to regulatory agencies, proving everything passes, etc. This is an intentionally tedious and slow process to make sure the device is safe. Doing the whole release cycle more frequently can be way too time consuming, and it just doesn’t work in conjunction with the agencies.
In supporting medical device companies, we have seen many scheduled webinars at the end of each iteration to preview what they built in the last iteration in action. Depending on what you are building, you could also give a version to select customers as long as it won’t be directly used for care or diagnosis on current patients. As an example, a customer could obtain the current iteration in house for a blood analyzer, and they could load it with real patient data and test out the new functionality, but not use it to diagnose an existing patient because it hasn’t gone through regulation.
The trick really is then to synch the official release into the current processes around hardware release, testing and everything else the company has. This is doable but takes some time and careful planning so everyone is on the same page about how everything will work.
In fact, agile development has gotten so popular in medical device companies that the AAMI (Association for the Advancement of Medical Instrumentation) is currently working on new guidance for mapping agile to a medical standard called IEC 62304 (a medical device standard specific to regulations around software). To comply with this standard, which is recommended worldwide, companies need to show traceability across their whole software lifecycle. This traceability needs to encompass requirements to architecture to code and tests. The importance is the focus on software, not complete devices — regulatory agencies no longer want to see how each piece of a device complies, but how the software design as a whole complies with regulations. The issue is that the data in the standard shows a waterfall process while not proposing a specific process. The AAMI received enough requests from customers to add guidance for how to map it to an agile process that they are working on the guidance now.
Another question is how can I make an agile process work when targeting an embedded device? This is a challenge as agile promotes developers to test their device frequently. In many cases, though, hardware availability is limited and it is in a lab that isn’t convenient to the developer working at his/her desk. There are a couple of ways to manage these issues. One is to use some sort of simulator of hardware itself. Many real-time operating systems offer simulators that work well. In addition, if you choose to model your design in a tool like Rational Rhapsody, then it has the ability to run a simulation of your actual on your desktop to see how it executes.
In many cases, while executing on host or simulator works, it doesn’t work when you have to talk to specific hardware to see the actual response of the hardware itself. In those cases an addition to agile called Continuous Integration helps. The concept is pretty simple. As you build a story make sure you do frequent check-ins and then build into your check-in process the ability to do a build of the device and then have the configuration management environment schedule the tests to be run on the device. Automating your build process can make this much more seamless so testing and integrations occur much more frequently. This way the build engine can work with a scheduler to manage access to at least some of the physical hardware so developers aren’t fighting for the scarce resource.
In conclusion, agile development works and is being used in medical device development. The issue is that you need to have a good tool chain that allows for complete traceability across the entire lifecycle in order to comply with standards. It also is very important to integrate and test frequently. This in turn leads to the need for build automation. With all of this in place agile development for medical devices becomes much easier get up and running.