When do Design Controls Start?
For medical device companies developing new products, one of the more difficult compliance aspects is are design controls as described in 21CFR§820.30. This is important for the regulatory affairs (RA) manager because the outputs (e.g. drawings, bench testing, manufacturing processes) of the design control process are used to develop the premarket notification (510(k)), investigational device exemption, or premarket approval submission. Sometimes acting as the only compliance entity on a design team, the RA manager must educate the team on design controls.
Increased compliance risks
There are numerous problems associated with incorrectly initiated design controls. The most obvious problem to the RA professional is the increased compliance risk associated with a poorly executed design control process. This could result in a rejected or delayed submission as well as a warning letter or 483 for a currently marketed device.
Most new product development efforts result in numerous ideas that are rejected for failure to meet the functional requirements. If the testing for these early concepts was included in the design file, then the failure data will also be there, albeit without a formal failure investigation identifying root cause and corrective action. As a result, an investigator would question the safety of the finished design if it appears that the design process was sloppily conducted.
The other compliance risk is increased complexity by including additional development cycles to the overall design. By having every concept and early prototype data in the design file, it creates a documentation nightmare for both the design team, RA professional, and the investigator. If a product idea generates 10 concepts, 5 early prototypes, 1 final prototype, and 1 finished device, then the design file should only include the data for the final prototype and finished device (assuming the final prototype was used to verify/validate the final design). Even if there was less documentation for the early concepts, the sheer number of them makes the entire design more difficult to trace. Particularly if the design file is completed near the end of the development effort, it could be very difficult determining which final concept was “approved” and which were rejected.
Longer Development Times
The other problem with a poorly executed design control process is the increased development time. While this may not seem to be a regulatory issue, the fact is the regulatory function is at the end of the design process and any compression of the design schedule will happen there. How many times has a submission that required four weeks to complete been written in four days? It behooves the RA professional to get involved in the design process early to ensure that the team stays on schedule.
Time can be lost due to the effort of executing a formal change control process to frequently changing early prototypes and designs. When design controls are initiated, all design changes must be reviewed for impact to studies already executed and approved. Since these are early prototypes, there is no reason to suspect they would have any effect on the overall design, but they will have the documentation effort of maintaining change control, which is not exactly a small chore.
Likewise, there will be some needless testing to early concepts and prototypes if design controls are executed too soon. If an engineer or technician knows that he or she must get a certain test done to release the design, he could end up executing it on all of the concepts. Like it or not, new product development can be a chaotic process and undoubtedly there will some testing done on early concepts or prototypes that was not required if design controls are prematurely initiated.
A great example of this would be a pre-clinical safety study conducted on a prototype that has physical dimensions different from the final approved design. Since pre-clinical studies are often the critical path on a project, they tend to be run as soon as possible. With this case, it is possible the that entire study would have to be repeated since the change in physical dimensions may lead to an increase in the chance for patient injury.
Higher New Product Development Costs
The final problem associated with premature design controls is the increased development cost. While not directly a regulatory concern, it does affect resource availability later on. Money spent on a repeated pre-clinical trial takes away from a new study to show safety that could increase the probability of submission acceptance by the agency. With more effort spent documenting early concepts and prototypes and multiple instances of same test, the design process will undoubtedly be more expensive.
Design Concept not Complete
The first guideline to understanding when to start design controls is that the design concept must be fully understood. If the design is not understood, it cannot and should not be controlled. This is generally referred to the design concept phase.
Understanding the design from an engineering perspective means that all of the functional requirements have been specified. While there may still be questions as to how the requirements will be met, the requirements should be known. Examples of functional specifications are: desired therapeutic effect, sterility, package type, some critical physical dimensions, environment, and product performance requirements. A good rule of thumb is that if a design can be sketched on a piece of paper with all of its packaging in the area of use, then the concept has been developed. Design controls also cannot be implemented if there are functional requirements that have not been implemented in the design. In this case, most of the design is conceptualized, but there are one or two questions still remaining. For example, if a sterile device is to be developed, functional requirements for the packaging must be developed as well. It is a very poor idea to start a sterilization validation, if the packaging is unresolved.
Feasibility Studies Incomplete
The second requirement to move into design controls is that the design must be feasible. Feasibility implies that testing, literature review, and/or market research will be conducted to determine if the design concept can actually be developed. This is also a tricky requirement, because many people feel that once testing is executed, it must be part of the design file. This is incorrect, while the data must be documented in a laboratory notebook, test data at this point is exploratory and not formal verification/validation. In other words, experiments done at this time do not require an approved protocol or acceptance criteria. It is this data that determines the acceptance criteria, operating ranges, design specifications for the final prototype, and subsequent verification/validation activities.
Feasibility has also not been established without a formal risk assessment. Two common techniques of risk assessment are failure mode and effects analysis (FMEA) or fault-tree analysis (FTA). Without risk assessment, the design team is unaware of the specific risks associated with this design. Risks not only drive the decision to move forward with a design, but they also highlight new functional requirements specific to safety. This is a fundamental requirement of design control and starting design controls without a risk assessment is foolhardy. An example of this would be an injection molded medical device. If the risk assessment found a significant chance that a breakage might occur and this would injure a patient, then a new functional requirement for the stress limits of the plastic would be added to the product specification. The final requirement of feasibility is the translation of the functional requirements into a design specification. The design specification is also referred to as design inputs in 21CFR§820.30. Without design inputs, there is nothing to drive verification/validation. It is during feasibility that the design is finalized and that specific, measurable design and development activities are planned. It is not possible to assess if all of the design verification/validation studies were completed without this step. How many times has an RA manager been writing a submission to realize that someone forgot to send samples out to the package testing lab or review the sterilization cycle printouts? The advantage of a complete design specification is that all subsequent verification/validation activities is traceable to one or more elements of the design specification. This also has the added benefit of eliminating unnecessary testing. Testing that does not verify or validate one of the design elements should not be performed (or the specification is incomplete.)
Conclusion
Compliance with 21CFR820.30 does not have to be a horror story. With a sound development plan, a design team can achieve all of the needed regulatory and quality objectives without sacrificing cost or the schedule. Key to this task is knowing when to start design controls and when to wait until the design has matured to the point where controls make sense.