Article

Agile in FDA Regulated Medical Software – Have Some Class

Michael Walkden

Published on: April 18th, 2011

This post was previously on the Pathfinder Software site. Pathfinder Software changed its name to Orthogonal in 2016. Read more.

The FDA states that a medical device is a product that is used for medical purposes in patients, in diagnosis, therapy, or surgery. As opposed to pharmaceuticals, who use the body’s metabolism, medical devices act mechanically or chemically. The FDA’s role in this is to assure the safety and effectiveness of devices. Keep this in mind while going through the process (they are not just to make your life hard).

From a software developer’s perspective, there are three classes of medical devices the FDA regulates. You should know what kind of product/device you are making very early on – before you start planning the work. There are legends of companies that have outsourced development only to find that their partner had yet to take a device to the point where the FDA would audit it. An even worse scenario: they had done the work with an offshore partner who didn’t fully understand FDA requirements and couldn’t prove traceability nor pass an audit. Whatever cost effectiveness a company offers, make sure it’s not going to be at the expense of doing the project twice.

Class I

Class I devices are not intended to be used for supporting life. As such, they have the least regulatory controls. Product development efforts lend themselves well to utilizing Agile practices. Do some research before you start development though. About 74% of devices are exempt from pre-market notification in the first place. Those that aren’t, might fit into an existing device panel. Often a few pages of documentation will suffice to pass pre-market approval for Class I devices. To find out more go to the FDA’s classification database.

Class II

For Class II devices, the FDA recognizes that general commercial quality control and manufacturing practices alone may not be sufficient to assure safety. However, they state that “existing methods” are in place to prove safety. You will still have to prove this to the FDA. Simply put: If you follow a process, and document it, you will be able to prove the device you are creating is safe. Rely heavily on documenting the history of the project well. The project will be characterized by significant documentation and process compared to a “normal” Agile project. Because Agile is quite new in the FDA space, you will probably need a seasoned compliance officer with FDA experience. Plan to get audited. This doesn’t mean that utilizing Agile practices is difficult or shouldn’t be done. In fact, because so much time is spent on each feature of the software, I would argue that efficiency and managing waste become critical issues. Attacking risk and focus on delivering the highest value features first is key here. The team just can’t be sloppy with process or documentation for this type of device.

Class III

Class III devices are new or are used to sustain life. The team can’t rely on existing methods to prove to the FDA that the device is safe and labeled correctly. Time to market will play a part, but software development isn’t likely to be on the critical path of product development. The raw science and research are likely to take up most of the product lifecycle. Is agile right for R&D? That’s a topic better covered in another blog post.

Given the wide range the FDA has in place, the life of your product development team will be greatly affected by the classification of the device you are creating. In my experience, working on Class I and Class II devices often feel like working on a “normal” Agile project – assuming your Agile process incorporates enough controls to document the process itself.