Do you want to improve your design controls documentation? If so, the first step is to evaluate how your current processes and procedures are working and how effective their results are. To work through this process, there are six important questions to ask, ranging from your design outputs and risk management to the current state of your product data across multiple sites. Answering these questions thoroughly and honestly can empower greater levels of design controls compliance in your premarket submission activities.
1. Do the design outputs conform to my design inputs?
When compiling your finalized design controls documentation for premarket submission, this is a necessary question to ask. You need to establish evidence through your design controls activities that whatever design outputs you produce—materials, design specifications, components, and so on—conform to and relate back to inputs you have incorporated into the product design. Addressing this conformity should be a top priority for your development teams.
2. Is there a logical trace from my user needs to the lower level requirements?
While on the topic of design inputs, it’s important to take your requirements flow into account in the documentation process. Going both up and down this flow, there should be a clear indication that your lower level requirements fulfill your user needs, and that those user needs logically evolve into your system and subsystem requirements. Utilizing traceability, these relationships are easier to identify and understand.
3. Has risk management been incorporated comprehensively?
While risk management is not an explicit part of the design controls process, it is an important factor when generating your documentation. The intended use of your product and the numerous requirements created to fulfill your user needs carry with them some level of risk. Therefore, making sure these requirements have been analyzed and controlled through your risk management programs can strengthen your design controls compliance.
4. Who has touched or altered data, and why?
Seeing which team members are touching your design controls data is not an immediate concern in creating your documentation. However, having that understanding in place before reviewers see your premarket submission can be beneficial. Looking at and reviewing this metadata allows you to detect design issues, rework, or anything else that might result in lost time to market or remediation.
5. Does the data need to be retrofitted into a compliance-ready format?
Many development teams focus first on generating product data. As a result, the process of generating the necessary compliance documentation gets left as an afterthought. This can create a number of issues, especially when product data needs to be retrofitted to a compliance-ready format. To overcome these problems, consider adopting approaches that focus on generating your design control documents as you go.
6. Is the data being compiled into my documentation the same across multiple sites?
Uniformity of your design data is an absolute must in life science product development. When there are disparities in even one requirement or other data point, the room for errors increases. For organizations that work with multiple remote sites to gather their design control data, this is a major concern. Being able to baseline your product information reduces the chance of error and maintains team cohesion across work sites. Along with the other guiding questions for design controls documentation, this one is especially important to think about.
