All the Compliance; None of the Benefit

In one organization I recently joined, I was speaking to members of the R&D team on a large multidisciplinary project, encouraging them to “bite the bullet” and enter design control. The project was years behind and battling regressions they previously had solved. With wide eyes, they exclaimed that the project was not "ready" for design control and expressed concern that the requirements of design control would bog the project down. I asked them what requirements they were specifically concerned would slow them down. They replied with conviction that they would have to do an impact analysis every time they made a change, which they had "no time" to do. The lack of impact assessments was, of course, a primary reason why the project was constantly chasing its tail; the hardware team would make a change that affected the software team, who would, in turn, make a change affecting the reagent team, and so on.

This fear of design control is not uncommon and has led to a philosophy among many where design control is viewed as merely a burden. The prevailing belief is to put off its application as long as possible until it's absolutely mandatory for compliance with FDA and other regulations. Usually, this means that somewhere between design freeze and the beginning of formal design verification, the project flips a switch and declares that they are a medical device project under design control. Suddenly, a fully developed medical device is birthed, ready for design verification, seemingly out of thin air (from an auditable documentation perspective). From an FDA or notified body perspective, this approach is acceptable and will not likely result in any nonconformance (at least not directly).

On the surface, this seems like an attractive approach; R&D is permitted to develop the device without people looking over their shoulders, and QA gets to tell any auditors that the project is not under design control yet, so there's nothing to audit in that area. This certainly makes an audit easier. The problem with this approach is that it fundamentally misunderstands the purpose of design control. The reason why standards and regulations require design control is that it is simply good engineering.

At its core, all design control requires is that you make a plan, identify customer requirements, translate them to product requirements/specifications, verify the product meets those specifications, validate that the product meets the customer requirements, and make sure what you transfer to manufacturing is what was verified and validated. In the end (and along the way), check the project against the plan to ensure you did everything you planned to do. If anything changes from the plan to the requirements and specifications, make sure the right people review those changes for any impact they might have on the rest of the project. Obviously, there's a lot of work and nuance in there, but that's it in a nutshell.

Most fear of design control is rooted in a lack of knowledge; people instinctively fear the unknown. In the example above, once the R&D team worked within design control with good coaching, they began to understand it; and fear resolved to confidence over time. One main misconception is that once you're in design control, everything you do requires the same level of scrutiny and documentation, which is not true. At the beginning, the project plan is the only thing under design control. Once customer requirements are released, those are controlled since a change in a customer requirement would have broad-reaching downstream effects. Product requirements and specifications should have an increasing level of oversight as the project progresses. Initially, a simple drawing released by an R&D engineer is fine. However, by the time you're ready to order parts for verification, those specifications should be matured with cross-functional review for adequacy and so on. In general, the level of control should be a slow ramp from project initiation through verification and validation.

The sad irony for the organization above is that they not only built up unresolved issues, or technical debt, but they also built up significant “documentation debt” as well. All the work they were afraid would slow them down still cane due; only now it came due all at once as a massive compliance hurdle without any of the benefit that design controls would have provided along the way: all the compliance without any of the benefit.

www.clearstratmedical.com