Our second blog post in this series surrounding Design Controls will focus on the initial steps in the process, Planning and Design Inputs.
Planning
While it might be tempting to jump to design specifics in the excitement of beginning a new medical device development or upgrade, it is essential first to create a design plan. The design plan should give particular attention to the key contributors to the design, both individuals and groups, and to the interfaces between them. Attention to interface ensures that all contributors are clear on responsibilities and can be held accountable for communication with other involved groups.
Design planning will necessarily start off with a low level of detail and be more general. As the plan is fleshed out by the various contributors, it should be updated. As the plan matures, senior management must be kept aware of the design plan, with particular attention given to the project completion date. There should be constant communication between the development team and senior management. That way, if the schedule becomes an overriding issue and dictates that changes must be made to simplify the design, it needs to be clearly communicated to management what the quality tradeoffs will be.
One aspect of design controls, design reviews, deserves specific notice at this point. During the design planning stage, a number of design reviews are planned as gatekeepers to key project milestones. Additional design reviews can always be added if needed, but it is crucial at the planning stage to decide precisely when discussions will occur. This prevents the design from arriving almost to the end before someone realizes no reviews have happened. A well-structured Quality Management System (QMS) will have requirements in place to ensure that discussions are planned and conducted at appropriate intervals.
Design Inputs
Design inputs are the physical and performance requirements for the device to be used as a basis for the design. Requirements should be unambiguous, not contradict one another, and be broken down hierarchically into their smallest complete elements. The requirements phase is perhaps the most critical design activity. If this isn’t completed thoroughly and correctly, it is difficult for the rest of the design activities to come off well.
Engineers are often eager to leap ahead into the actual development but can feel held back by having to refine requirements. However, projects that adhere to the discipline of a systematic start will finish more successfully and more quickly because the requirements were clearly understood and agreed to by all stakeholders. In our experience, it is not uncommon for the requirements phase of a project to encompass 30% or more of the entire project timeline and budget.
A robust requirements phase helps everyone on the project know what is included and what is not. It gives all team members more confidence to insist on new requirements that surface mid-project should get pushed to a future product revision. If all stakeholders determine that a new requirement must be admitted into the current development, it will be accepted with a clear understanding the addition will have budget and schedule impact.
Note that a concept document is not the same as a design input document. Concept documents are often qualitative, whereas design input documents translate the qualitative requirements into a set of quantitative ones. For example, “responds quickly to user interaction” may be replaced with “the interface shows response to user selections within 50 milliseconds”.
There is a significant difference between the “initial concept” created by the research group, a product that can be manufactured, and a product that can gain FDA approval. Prototyping and proof-of-concept developments have their place, but at some point, a company must move to disciplined, design control-based product development. The two are not the same.
In our next post, we will further break down the design input stage into its three main categories.
