Part 3: The FDA “Waterfall” and DeviceLab’s 6 Phases
You’ve all seen it. It’s one of the first slides in the Design Controls training class deck:
It’s a description of the interactions between certain factors and processes in the development of medical devices. In the white boxes are a series of steps from User Needs to the Medical Device, with progression governed by Design Reviews, and based on two comparisons: Design Output to Input during Verification and Medical Device to User Needs during Validation. This structure is a logical construct; more a map than a plan. It also omits the required steps of Design Planning and Design Transfer, but that’s because they don’t participate in the explicit feedback loops that are the meat of the diagram.
While this map is intended to drive the development process to a high assurance of safety and efficacy, it cares not about business imperatives and offers no help on how to actually design a device or run a project. This is deliberate – people can find many ways to accomplish things, and the FDA doesn’t care how you do it as long as your process incorporates the necessary controls and can prove that they work. So, each organization that seeks to develop a medical device must develop its own system for product development that meets regulatory requirements and works for their particular needs.
At DeviceLab, we have developed a framework for medical device projects that incorporates six phases (see the prior post in this series for more details). These phases are established to capture the elements of the waterfall diagram, as well as an iterative development approach so successfully employed in Agile Software Development. Of course, some projects are so much bigger or smaller than typical that this model can’t be applied, and often we get involved with a subset of the phases. However, this framework is a useful tool for thinking about the organization of a project, regardless of size.
So, how does our six-phase approach map to activities on the traditional FDA waterfall? While not an exact match, here’s what we deploy:
- • Proof-of-Concept maps to Design Planning
- • Alpha maps to Design Inputs
- • Beta maps to Design Output
- • Pilot Production maps to Design Verification and Validation
- • Manufacturing maps to Design Transfer
We work by incrementally chipping away at the very long list of things to do in digestible chunks along six parallel design tracks. We see the FDA Waterfall as a framework by which an evolving design progresses through successive versions, each accomplishing a greater portion of the requirements until they are all satisfied.
In our next post, we’ll talk about the six parallel tracks of activity that operate during a medical device project. You’ll learn more about how the project looks to each of the various disciplines involved and how they cooperate to achieve your goals. Please visit the Process and Compliance pages on our website to find out how we do things.