How do you prioritize and evaluate design changes based on their impact, urgency, and feasibility?

Design control is more than procedures and activities. To execute robustly it needs to be a discipline and a philosophy. Risk Management is a key parallel discipline to define hazards and harms, and then identify and evaluate potential failures. Human Factors Engineering is an integral part of both design and risk management. Design changes should be managed within a design controlled and risk managed framework with attention being paid to usability. All three principles should be worked hand-in-hand through product development and lifecycle management.

While design control is known to be used in the medical device industry, as illustrated by the FDA's guidance, its origins extend beyond this field. Design controls are simply the good practices of any well-managed engineering project. This approach aims to prevent unauthorized changes that could cause performance or safety issues by ensuring that new or modified product designs are assessed, approved, documented, verified, and validated. This ensures that the modified design remains safe and efficient. While this workflow is commonly used in the V-Cycle development framework due to its structured nature, it can easily be implemented in any framework, such as Agile, provided the teams are very disciplined.

Management of ANY change is crucial. Design changes are just one subset of changes that can have impact on a medical device or device constituent of a combination product. Before any decisions can be made the change needs to be properly defined, carefully evaluated, with impacts and considerations being well understood - ideally BEFORE implementation. Design controls, RM and HFE principles are key to understanding, controlling, verifying/validating the change. I have experienced a pharma filling machine undergo >300 changes in a 3-year period - each one being positioned as a necessary ‘improvement’. At the end of the period, line was running at a fraction of its initial performance and required a complete rebuild and full requalification.

Not managing product modifications can lead to critical failures of deployed products or safety and performance issues throughout the product lifecycle, including manufacturing and servicing. A recent example of poorly managed design change is the CrowdStrike incident in July 2024. In this case, the impact of a software change was not adequately assessed, and the modified software was not properly tested before worldwide implementation. This caused 8.5 million Windows OS-operated terminals to crash, leading to significant disruptions in air travel. Moral of the story : never release a new design version without having performed at least an exhaustive impact assessment and an appropriate testing.

Although the urgency and impact criteria are effective, there are other planning factors eg compounding changes and when it is best to make them. If injection mould tools are down in a months time for routine maintenance there is an opportunity to implement a change without increased downtime. Similarly if multiple changes would each require regulatory approval processes, it may make sense to make them together and execute a single regulatory notification- rather than several.

Design changes that address flaws affecting the safety and/or performance of your product should always be your absolute top priority and supersede any other changes. Other types of changes, such as improvements or new functionalities based on user feedback, should be assessed for their compatibility with each other and with the product roadmap. You may include multiple design changes in one product release, but you need to ensure that the changes do not conflict with each other and that you have all the necessary materials and human resources to perform the design controls adequately. Do not prioritize a design change without evaluating its impact on the entire product lifecycle, including manufacturing, suppliers, distributors, etc.

A ‘checklist’ does not provide the technical understanding needed to properly evaluate a change, but it can act as a prompt to address common areas; and to provide certain consistency. Ultimately only those who have deep technical knowledge of the product can effectively understand the implications. It is quite often the case that one change requires others to accommodate it properly and these often are only identifiable by those in the know - not by a checklist.

I recommend that you implement Change Review Boards (CRBs) within your product change process. A CRB should include a set of technical, regulatory, and business experts who together cover the entire product lifecycle. This team provides clear insights into the relevance, impact, and feasibility of the change and follows its implementation. I suggest you include some external experts within your CRB. Having an independent external point of view can often help identify potential impacts that may not be recognized when working routinely within the company. The CRB should study Change Request, and give an unanimous approval for its implementation within the product Roadmap.