Design Article
Using agile methods in medical device development
Martin Bakal, IBM
10/9/2012 9:17 AM EDT
Page 2
This works well when updating an application that goes on a webpage but how can you achieve this when building a physical device that had a long regulatory process for each release?
One way to do this is to demo the new functionality created after each iteration to your customers, using web-based meets. Using these tools enables you to get immediate feedback from your customers throughout the project. Continuous customer feedback reduces the risk of building the wrong solution. The fact is in most cases you can’t make the release cycle more frequent since it includes giving tests to regulatory agencies. This is a tedious process that makes sure the device is safe. Doing the whole release cycle more frequently can be way too time consuming.
In supporting medical device companies what we have seen many do is at the end of each iteration they have scheduled webinars 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 will not be directly used for care or diagnosis on current patients. The idea there is the customer gets the current iteration in house for say a blood analyzer. They could load it with real patient data and test out the new functionality as long as it is not used to diagnose an existing patient, since it has not gone through regulatory.
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 does take 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 of Medical Instrumentation) is currently working on new guidance for mapping agile to a medical standard called IEC 62304. 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. This means that the regulatory agencies are saying don’t just show me how each piece of a device complies but show me how the software design as a whole complies with regulations. The issue is the data in the standard shows a waterfall process while not proposing a specific process. The AAMI got enough requests from customers to add guidance for how to map it to an agile process that they are working on the guidance.
Next: Page 3
This works well when updating an application that goes on a webpage but how can you achieve this when building a physical device that had a long regulatory process for each release?
One way to do this is to demo the new functionality created after each iteration to your customers, using web-based meets. Using these tools enables you to get immediate feedback from your customers throughout the project. Continuous customer feedback reduces the risk of building the wrong solution. The fact is in most cases you can’t make the release cycle more frequent since it includes giving tests to regulatory agencies. This is a tedious process that makes sure the device is safe. Doing the whole release cycle more frequently can be way too time consuming.
In supporting medical device companies what we have seen many do is at the end of each iteration they have scheduled webinars 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 will not be directly used for care or diagnosis on current patients. The idea there is the customer gets the current iteration in house for say a blood analyzer. They could load it with real patient data and test out the new functionality as long as it is not used to diagnose an existing patient, since it has not gone through regulatory.
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 does take 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 of Medical Instrumentation) is currently working on new guidance for mapping agile to a medical standard called IEC 62304. 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. This means that the regulatory agencies are saying don’t just show me how each piece of a device complies but show me how the software design as a whole complies with regulations. The issue is the data in the standard shows a waterfall process while not proposing a specific process. The AAMI got enough requests from customers to add guidance for how to map it to an agile process that they are working on the guidance.
Next: Page 3
|
|
|
|
|
Navigate to related information