Article

Launching Products Faster with Agile in an FDA environment

Bernhard Kappe

Published on: August 13th, 2015

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

We asked Dan Blake, Chief Technology Officer of Valence Health and former Senior VP of AirStrip Technologies to write a guest post with his perspective on the space:

Experience has shown me the challenges of working with Agile development in an FDA environment. But it’s also helped me understand how to make the flexible development style of Agile work within the strict constraints of FDA regulations.

FDA regulations require processes and documentation for the development of healthcare-related products, from medicines to devices and other products – documentation that’s complete and traceable. But on the development side, the industry is moving toward new methodologies like Agile, that create a more flexible design space that may not be easily aligned with the individual, separate steps that FDA regulations require.

Although FDA regulations and Agile processes are somewhat mismatched (since FDA has a propensity towards Waterfall-like documentation), the key to overcoming this challenge is aligning [DB1] your Agile process from the onset. If you’re working in FDA space, you know your processes and products will be subject to FDA regulations, so you should be proactive in making that approval process as easy as possible.

For example, at AirStrip, we spent a lot of time and effort making sure that we created our processes, tool sets and technologies so they very naturally lent themselves to creating the level of documentation needed in an FDA environment. This is somewhat at odds with the Agile principle of creating the minimal amount of documentation possible.

To that end, we did a lot of things with the tools and technologies we used to prepare documentation in an automated fashion at various points in the process. We tied user stories and acceptance criteria to automated tests, and used automated test execution that allowed us to prepare for the level of documentation and traceability needed by the FDA.

It’s all really related to the documentation – how you prepare it, when you prepare it, and knowing what the FDA wants. For FDA approval, you need to describe what you’re going to do and how you’re going to do it. Then, after the fact, you need to match your description with what you did and prove that you followed the process you laid out.

And all of this can be done within the actual framework of Agile – once you determine the best way to document your requirements at a sufficient level of granularity via user stories. By tying everything to the story and acceptance criteria, including the automated tests, you can use the system itself to prove that your completed product matches the description of the system.

You really have to view creating the documentation as an output of the process. And what I mean by that is, if you say, “We’re still going to try to do Agile but we’re going to do this huge online design,” you’ll fail. You have to commit to doing Agile, and in the process of doing Agile, also commit to accumulating everything, and to create a living, ongoing document. With this mindset, at the end of the project, you’ll have a document that will be exactly what the FDA is looking for in a typical design specification.

In reality, the FDA is more focused on your company’s development process than what you produce. The easiest way to comply is to take an Agile process and align it with a set of Waterfall-like artifacts. These can be set up behind the scenes, to avoid distracting your project members from the difficult flow and cadence that you strive for in a normal Agile process.

Although FDA regulations and the Agile method may seem to be at odds, the FDA is evolving to embrace new methodologies where they make sense in healthcare industries. Keeping up with the quickly changing field of software engineering, especially in healthcare, is challenging for people in the industry, but it’s even more difficult for the managing and regulatory institutions.

I think the regulatory environment’s relationship with the Agile method will continue to evolve, and the key to surviving all the changes is a good partnership. Make sure that you, the organization, and the partners that your company is using to develop products in the FDA environment (like Orthogonal), are truly Agile in what they do. Particularly in the sense that their process system cells are agile – they can adapt and evolve very, very quickly.