Many medical device companies struggle to understand the scope of design control, with the result being an ineffectual application of wasted effort. To maintain a lean and agile development process, it’s crucial to have a clear understanding of exactly what ISO 14971 requires.
I’ve seen misguided project managers insist on detailed record keeping of early development, with painful revision tracking for a myriad of informal design iterations.
What is in scope?
It’s easiest to answer this with the negative case.
In short, any development activity prior to verification is out of scope for design control.
Regulatory agencies don’t care about records of any development, prototyping, or experimentation performed prior to the start of verification.
Sure, you need to have development plans. This is when you need to establish your design inputs – what are the requirements of your design that will need to be verified later on in development? This is also the time to perform a preliminary hazard assessment to avoid major changes late in development.
But when it comes to the actual design outputs, such as CAD models, drawings, BOMs, tooling, and fixtures – anything goes!
Early prototyping and technical development should be done quickly, with rapid cycles of iteration. Engineers must not be constrained by the burden of documentation and record keeping for early design and experimentation.
When the design is finalized and ready for verification, only then should a formal design control process be implemented.
DESIGN FREEZE
“Design freeze” is the flag in the ground to deliberately demarcate the boundary at which design control is initiated. At this point, the design is formally released to a controlled state, in preparation for verification and validation. Once design freeze has occurred, all subsequent design revisions need to be reviewed and approved by the change control board.
However, even once design freeze has occurred, informal proposed design revisions may still be created and evaluated outside of design control. Revisions only need to be formalized in the DHF when a decision has been made to move forward with a proposed design change. There may be multiple proposed design revisions along parallel paths, with only one version moving forward as a formally controlled design change.
DOCUMENT DRAFTS
The same philosophy applies to DHF and DMR document revisions. Some quality managers insist on keeping detailed records of informal document reviews and draft revisions. This is a huge time sink, and isn’t required by regulatory agencies. Document drafts need not have any record of informal revisions and reviews. Formal document reviews only need to be performed on the proposed release version. Working document drafts are outside the scope of design control.
EQUIPMENT QUALIFICATION
The same philosophy applies to equipment qualification. I’ve seen quality managers insist that every piece of equipment in R&D be qualified. This is easiest for them, but toughest for everyone else, not to mention tough on the company’s operating expenses. This approach should be avoided at all costs. Any equipment which is once qualified will invariably become part of an “equipment maintenance” program, which creates a perpetual burden to keep it qualified, even though that equipment may never contribute to the fabrication or verification of any controlled product. This task means job security for the quality department. But none of this perpetual work load will add one cent to the company’s bottom line. The more sensible approach is to intentionally qualify only that equipment which will contribute to a formal verification cycle. An effective training program and equipment labeling are sufficient to ensure unqualified equipment is not used for formal development and verification.
Cyclops Engineering 