When developing medical devices, a manufacturer may have difficulty knowing when (or what) the transition from research phase activities to design controls has begun. Often this is due to the nature of research itself – one is exploring a concept or design approach that may or may not pan out in the end. The US FDA has traditionally applied low scrutiny of medical device research phase activities in an effort to minimize the regulatory burden on the research process. However the manufacturer is obligated to clearly define when research activities have come to a close and design controls (21 CFR 820.30) would apply. In some cases, a manufacturer may not even be aware that software “lifecycle” documentation is required to demonstrate software quality and formulate a software validation argument.
A common mistake in this area is to treat this transition from research to design controls as a “binary” – that is, attempting to declare “research is done – now start design controls.” While this may seem to be a proper approach from a regulatory standpoint, this binary type approach can be counterproductive. An alternative approach that is more efficient and sustainable would be to define “maturity” levels for the research activities – where these maturity levels would represent progress toward “design input.” Design input, by definition, starts the Design Controls activities. Research phase activities should have as a goal to clearly define Design Input and correspondingly define how Design Validation will be accomplished. This will involve multiple disciplines including regulatory.
This approach might be illustrated as below:
While this illustration is SaMD focused, one could adapt to SiMD as well.
Final thoughts:
- Ensure that the research activities, if continued, will result in clear “design input” to the design process and clarity as to how “design validation” will be performed and executed.
- Design input cannot be complete without the device level risk analysis.
- Recognize when an activity will require documentation necessary to show software lifecycle quality assurance processes. Likewise, don’t unnecessarily burden the research process when an activity is clearly research – and that later design control activities will “re-develop” the designs.
