Imagine the following scenario. You arrive at work one day, perhaps to the corporate headquarters of My Quality Device, Inc. (see our first article “Setting the Stage and Initial Thoughts”). Waiting in the lobby are two people. They show credentials as auditors for the FDA, and declare they are there to perform an audit. You scramble to find a room, and offer them a cup of coffee (which they decline). They indicate they want to see the Quality Manual, the Product Design SOP, and the Design History File and Device Master Record for your new product, the “IOMDD.”
In the vignette in our first article, the design of the IOMDD was rushed by management and the project management group. The project team was not clear on the requirements they were designing to, and at one point, the project champion stepped in and said, “do it this way.” Because of this history, several things are present, and not present in the Design History File. Not present is a clearly defined and consistent list of product requirements (design input requirements). Instead, some are vague (which makes them difficult or impossible to verify), some conflict with other requirements, and some are not present at all. The latter are identified by the auditors because production is monitoring and controlling “critical” design output that has no linkage to any design requirement. Because of the large number of requirements that are defined, the auditors are not able to understand how the requirements relate to each other. The auditors are also unable to clearly understand how the design outputs relate to and conform to the design input requirements. Finally, it is clear in the documentation that a number of the requirements were defined after the corresponding design output was defined, and there is little or no justification noted for the reasoning behind most of the design decisions.
Worst of all, the identities and locations of many of the documents are not clearly indexed: and the auditors are frequently left waiting for extended periods of time while documents are located or accessed from old emails. The auditors eventually leave after issuing a 483 notice with many observation points. A few weeks later a Warning Letter is delivered to My Quality Device, Inc.
There are a number of points to take away from this scenario, but fundamentally they all come down to the following: It’s all in the story.
In the end, one of the fundamental objectives of quality systems in general, and design controls in particular, is to clearly document how a design team translated input requirements into both design outputs and manufacturing processes. This may seem like unwanted extraneous work – a “hoop” we just need to jump through. In reality, this objective of quality systems is actually of critical importance to high-quality product for the following reason: if you have done the design input work, the design analysis, and the organization of that analysis so as to enable clearly documenting it, then it is much more likely that the quality of the design process is high. The converse of this statement is: haphazard work will yield haphazard documentation of that work.
In the end, the objective of this aspect of quality systems comes down to building confidence, in the eyes of a reader days or years after the fact, in your design process and the resulting design. The rigor and requirements imposed by quality systems are intended to force a minimum level of documentation to demonstrate that appropriate levels of engineering practices have been followed. As we said in our article A Quality System is not Enough: “The regulatory expectations only add one thing (to the engineering practices): provide reasonable evidence…”
The importance of that point of “reasonable evidence” cannot be understated. First, regardless of the “correctness” of a design, if the process is not documented clearly it will leave auditors and potential buyers confused and lacking confidence in your business and your products. Second, the last thing we as a design company want is for auditors to be confused – either about how one document relates to another, or how a design decision relates to a design input. Crisp answers to questions, rapid and confident production of documents asked for, and clear explanation of design rationale breeds confidence in your organization and design processes. Confusion in answers, lack of ability to produce documents, and, especially, demonstrated lack of awareness of regulatory requirements and expected engineering practices leaves the auditors lacking confidence in your systems and practices. This latter situation is what gives rise to the description of an auditor “smelling blood in the water.”
The second facet of understanding the implication of “…provide reasonable evidence…” is even more important and powerful: by telling a story clearly, you force yourself to critically understand what you have done in your design. Forcing clear documentation of a design process (and related activities) thus increases the probability of yielding high-quality product. There may be, and frequently are, complaints by designers that “… I know what to do: all this documentation is slowing things down.” Well – yes. That, within reason, is the very point. Anyone who has been a teacher will note that you do not really understand material until and unless you can explain and teach it clearly. The same point applies here: we may think we “know what to do” … but unless we can explain, document, and defend it clearly, the opportunities for mistakes or overlooked problems with a design are magnified.
The last point to note here is that, while exactly following the prescriptions and processes of a quality system is important, it is not absolutely necessary. Even the best quality systems cannot foresee all that can arise in all future projects (and in the authors’ view, they should not be designed with such an objective). It is entirely possible, and actually common, for a project closely following a quality system to yield a conclusion that … just does not make sense. We saw this described in our vignette in the first article where the design team was forced to closely adhere to the quality system, but ended up reaching conclusions that defied common sense. The thing to do in this situation is to step back, carefully define an alternate conclusion (or approach), and to document: 1) that this is a deviation from the quality system, 2) what the alternate conclusion or approach is, and 3) what the (defendable!) rationale for that differing conclusion is. It is far, far, better to pull out that document and show it to an auditor (which portrays confidence and awareness of the situation) than to take either of the alternate approaches of not documenting the deviation from the quality system (which portrays lack of awareness of the quality system to the auditor) or accepting and moving ahead with the illogical approach – which will most likely result in a quality issue (or added expense) in the design product.
In conclusion then, our very ability to instill high-quality into our products and to demonstrate that high-quality is driven by the clarity and quality of the story we can tell about that design process.
The key takeaway points here are:
- Enforce clear and understandable documentation, both between and within documents. This will naturally enforce quality and robustness of the associated engineering and design work
- This means:
- Clearly document what was done (and at times what was not done). This applies to selection of design inputs, relationships between design inputs and design decisions, and relationships between design decisions and manufacturing controls.
- Clearly document how design decisions were reached. This makes those decisions more defendable and more likely to be robust.
- Be willing to deviate from the quality system if it clearly leads in a nonsensical direction. Clearly document when the quality system is deviated from. This includes documentation for the alternate approach, and clear rationale for taking that approach.
© 2017 DPMInsight, LLC all rights reserved.
About the Authors:
Over 27 years of experience in industry, including 20 years with Medtronic, where he worked and consulted with many organizational functions, including research, systems engineering, product design, process design, manufacturing, and vendor management. He has also worked with development, regulatory submission, and clinical trials of combination products using the pharma (IND) regulatory pathway. He has been extensively involved with quality system (FDA and ISO) use and design, and is particularly concerned about effective understanding and use of product requirements and design controls. He has formally taught elements of systems engineering, design for six sigma, Lean, and six sigma. Cushing has degrees in chemistry and chemical engineering, is certified as a Project Management Professional, is certified as a Master Black Belt in Lean Sigma, and is the owner/member of DPMInsight, LLC (www.dpmillc.com).
Michael B. Falkow
Michael Falkow is a Quality Specialist with Raland Compliance Partners. He has served as a regulatory compliance and quality assurance executive with multi-facility/international companies and was an FDA Compliance Officer and Senior Investigator/Drug Specialist. Michael has subject matter expertise for quality and regulatory compliance, quality auditing, quality assurance, quality control, supplier evaluation and certification, and compliance remediation. He has been approved by FDA as a GMP certifying authority and is qualified to provide Expert Witness testimony for GMPs. Currently – Adjunct Professor at Mercer County Community College – teaching courses on Clinical Development for Certificate Program in Clinical Research as part of Drexel University’s Masters Degree in Clinical Development.