Nobody sets out to write design control procedures that undermine medical device development, but unfortunately that’s the situation I’ve observed at many medical device companies. Over the past 20+ years, I’ve worked on a wide variety of medical device development projects (>50) under many different quality systems (>25) at small and large companies. From this experience I’ve learned much about what works and doesn’t work with design control procedures.
In the previous blog post What Are Medical Device Design Controls? I pointed out a few common misunderstandings of the basic concepts associated with design controls. Here I’ll discuss some specific ways we undermine good product development with poorly designed or misapplied design control procedures.
Mismatch with Products and Organization
“The right way to do design controls is the way we did it at my last company!”
(misconception: there’s only one way to comply with the regulations)
Sometimes when I meet with a new client and suggest an alternative approach to some aspect of design controls (that a previous client used) I am told emphatically “You can’t do that!” I’ve learned that what they really mean is: that’s not the approach we’re familiar with so it must not be compliant. If you only know one way to implement design controls then it can seem very risky to try something different (“What if we fail the next audit?”). As a consultant I work with a wide variety of design control procedures and I know many alternative approaches. For example, I’ve worked with product life cycles that have as many as 11 phases and as few as zero phases. All of these approaches were compliant but different, with different strengths and weaknesses. The challenge for each medical device company is finding the best approach for their products and their organization.
An extreme example of mismatched design control procedures that I observed was a small medical startup with less than 20 employees trying to implement quality system procedures copied from a global company with thousands of employees. They wasted a lot of time for months before jettisoning the ill-fitting procedures and adopting new ones intended for a smaller organization.
Most of the examples of mismatched procedures involved applying design controls optimized for relatively simple, hardware-only devices to complex devices with software. For example, a client that had only produced sterile disposables acquired a company that made complex capital equipment. They tried to apply their design control procedures to this equipment company and were perplexed and surprised that it didn’t work well. After all, they had passed many audits over the years. So what could be wrong now? Design controls optimized for simple medical devices do not provide sufficient scalability and flexibility, so they can systematically undermine development of complex devices.
For example, the “Design Inputs” for a simple device will be managed very differently for a catheter versus an ultrasound or radiation therapy system. Conceptually, they are the same element of design controls but practically the methods are quite different as anyone who has wrestled with hundreds or sometimes thousands of design requirements can attest.
Mismatched procedures may end up forcing a product team into awkward compromises. The product team must choose between doing what’s best for the product or what the quality system procedures requires. This in turn can lead to long-term compliance problems and repeated audit findings (and CAPA’s).
Compliance Over Knowledge
“Just release the documents”
Do you consider design controls just a way to generate documentation to pass audits? Even if no one says this out loud, it’s a viewpoint I’ve encountered many times over the years. Design controls are one of the most common areas of audit findings, so medical device companies are naturally sensitized to compliance in this area. However, that shouldn’t overshadow the purpose of design controls as a framework for sound product development.
We often over emphasize the phase-gate aspect of design control procedures. As a result, we don’t focus enough energy on the overall product development process and on solving tough technical problems with an innovative new medical device. For example, at a design review to complete Phase ‘X’ we carefully note that all of the DHF documents needed at this milestone have been released. But we may gloss over a performance problem with a prototype or a fabrication problem in an early pilot run. By focusing on the documents more than the product, we don’t work on solutions to technical problems: worse, we give the illusion that everything is OK for the project to move ahead.
Theoretically, a product team should not be able to release the required DHF documentation without addressing technical problems with the product. Practically, that often happens under pressure to move a project forward and the problems are not resolved until much later when it is much more expensive. Some typical problems I’ve seen in development projects that caused big, expensive delays late in the project are:
- Inadequate reliability in mechanical components and assemblies
- Usability issues
- Issues with cleaning and sterilization
- Supplier capability and related issues
- Hardware-software integration issues
Design control procedures that put product issues front and center will force the product team to focus on resolving the issues. Procedures that only focus on documentation may appear to be fully compliant but can easily mislead the team (and senior management) by masking some serious problems that will blow up later if not resolved.
Documents Structured for Audits, Not Product Development
“Let’s Put All the Eggs in One Basket”
In many of the quality systems I’ve worked with, the structure of the DHF documents seems to be optimized for audits, not for product development. I suspect this is the result of unpleasant experiences in the past of scrambling to find information under the withering gaze of an auditor. Or of finding out during an audit that one document was updated but another was not.
For example, many companies utilize a “Design Input Output Matrix” or “Design Verification Matrix” or related document which contains virtually all of the design control documentation for a product (requirements, specs, tests, etc.) in a large table. This may have seemed advantageous years ago when the only tools we had to manage product information were MS Word and Excel but isn’t anymore. I believe the intent of this single, big matrix approach is to simplify traceability amongst different elements of design controls by putting them all in one document (“Since it’s so hard to keep the product documentation up-to-date and traced, let’s just put everything in one big document.”). Nowadays, however, there are many sophisticated software tools to manage complex product data and traceability so we can have much more flexibility in structuring DHF documentation.
For more complex medical devices (such as IOT products, imaging systems, diagnostic equipment, etc.), the single, big matrix approach does not scale well and is better replaced by multiple, smaller DHF documents. This more modular approach makes it easier to write, review, and maintain the documents for the life of the product. As an extreme example, I once worked with a client who had dedicated two employees full time just to maintain their Design IO Matrix document during development of a piece of capital equipment (very inefficient!).
Finding needed product information during an audit is important but it shouldn’t be the only consideration in structuring your DHF documents. Audits only occur occasionally but a product team interacts with DHF documents frequently and proper consideration should be given to how to optimize for writing, reviewing, and updating the documents from the viewpoint of the product team. If you find product teams repeatedly struggling with writing and updating DHF documents, maybe you need to reconsider the structure and format of those documents and look at alternatives that better align with how the teams operate. A good ALM system and other software tools can give a product team the best of both worlds: straightforward writing and updating DHF documents as well as complex traceability matrices and other reports for efficiently finding product information during an audit.
Conclusion
No quality system procedures can guarantee that all new product development projects will be successful, but poorly designed procedures can systematically undermine every project. Fundamentally, design controls should be focused on producing safe and effective medical devices. Avoid falling into the trap of focusing only on DHF documents and not on the product. Carefully considering the needs of your company and the types of medical devices it develops and then optimizing your design control procedures around those needs will give every product team the best shot at success.
Pingback: Newsletter V. 2022 Issue 2 - Sunstone Pilot, Inc.
Yet more sage advice from Aaron; thank you. I’d like to highlight his recommendation to break a large DHF into smaller documents. Consider a device that uses a component, e.g. an ultrasound transducer, which is also used on other devices with their own DHFs. Often the design of that transducer is part of the DHF for the first device to use it, but when a second device, with its own DHF, uses that transducer, traceability and control get murky quickly. If that transducer had its own DHF, then each device could include the transducer DHF by reference. Changes to the transducer wouldn’t change the DHFs of the devices except for those parts which are affected by transducer changes, such as EMC and safety testing, labeling, instruction manuals, and so on.
Yes, that’s a great example of the challenges of documentation with more complex medical devices. Without a certain degree of modularity and flexibility, product teams will really struggle with the DHF documentation.