What Designers and Engineers need to know about Design Control
When developing medical devices many challenges must be overcome but Design Control does not have to be one of them.
Design control is a set of quality practices and procedures incorporated into the design and development process to control the design process and assure that device specifications meet user needs and intended use. The design control framework is often illustrated in the V-model or the following FDA-illustration:
A good project starts with a plan (1) describing the scope for the project. Then the first step in defining your Design Input is to identify the users’ needs (2a) These are then broken down into technical requirements (2b Design Input). The Design Process (3) is where the medical device is designed, and this process results in Design Output (4) such as specifications describing the medical device design. Formal Design Reviews (5) are performed where appropriate. When the medical device is designed it must undergo Design Verification (6) to ensure that the Design Output meets the Design Input. When the Medical Device (7) have undergone successful Design Verification, the Design Validation (8) is initiated to ensure that the final design meets the User Needs and Intended Use. Design transfer (8) ensures that the device design is correctly translated into production specifications. Design changes (9) must be assessed for impact and managed before implementation. Records of the design control process are contained or referenced in the Design History File (10).
Design control is best explained by an example. Imagine that you are designing a portable glucometer.
As we all know a goal without a plan is just a wish, so let’s start with Design Planning.
Design Planning (1)
Before starting the development project, design planning will help you ensure planning of:
- Design and Development activities
- Interfaces with different groups and/or activities
- When to perform Design Reviews
You will most likely have to revisit the plan throughout the project.
Design Input (2a and 2b)
The first step in defining your Design Input is to identify the users’ needs. You may identify one user need as: “The system shall be portable.”
This user need shall be broken down into system requirements (Design the product right by defining good requirements). These requirements shall not describe the solution. Examples of requirements that will ensure the portability of the system could be:
|Req 01||Weight of the system ≤ 0.8 kg||If the system is too heavy,
the user cannot carry it.
“The system shall be portable.”
|Req 02||LxWxH ≤ 0.3 x 0.2 x 0.2 m||If the system is too big,
the user cannot carry it.
“The system shall be portable.”
These design inputs are used in the design of your glucometer.
Design Process (3)
The actual Design process is not controlled but the input and output of the process are defined as part of the Design Control process. To better plan and control the development activities, we recommend defining a Design Freeze at an appropriate time in the process to ensure that further development is not implemented after initiation of Design Verification and Design Validation activities. In this phase, we also recommend performing informal R&D tests to ensure that design verification is attainable. This saves you the trouble of initiating a design verification that will fail.
Design Output (4)
After having designed the solution that will meet these requirements, you end up with your design output. Your design output is the specification and description of the solution the design ended up with.
- “Weight of the system = 460 g +/- 8 g.”
- “Dimensions of the system: L = 0.28 +/- 0.01 m; W = 0.18 +/- 0.01 m; H= 0.18 +/- 0.01 m.”
Design Review (5)
At all suitable design stages, design reviews shall be carried out
to evaluate the ability of the results of design and development to meet requirements and to identify any problems and propose necessary actions
Design reviews shall include applicable functions for the stage being reviewed, include an independent reviewer and be documented. Because of the formal requirements of design reviews, we recommend not having too many. You are always free to perform informal reviews of your design.
Design Verification (6)
Design verification activities verify that the device output meets the design input. According to the FDA, design verification activities include:
Already when defining the design input, you should think about how to verify them. We recommend inviting for a verification readiness review to ensure that the project is ready for design verification.
|Requirement ID||Description||Method of verification||Acceptance criteria|
|Req 01||Weight of the system ≤ 0.8 kg||Demonstration||≤ 0.8 kg|
|Req 02||LxWxH ≤ 0.3 x 0.2 x 0.2 m||Inspection of design output, specifications, drawings, etc.||≤ 0.3 x 0.2 x 0.2 m|
Design Validation (7)
Design validation shall ensure that the specifications meet the user needs and intended use. Design validation follows successful design verification and is performed using the final device or production-equivalent prototypes. The design validation activities typically encompass clinical studies, summative evaluation (also referred to as Human Factors Validation Test). Occasionally, not all user needs are validated as part of clinical studies or summative evaluation and will have to undergo separate design validation such as asking users to rate the appeal of the device or comparing it to similar devices on the market.
Design Transfer (8)
Design transfer refers to the activities necessary to translate design documentation into production documentation and prepare the production unit for full-scale production.
If the production facility is not able to manufacture a system according to the defined specifications, there is no point in trying to produce the system.
Design Changes (9)
It is important to have a process for evaluating the impact and consequence of design changes. Change of a device component may have consequences on the performance of the device. Therefore, you shall evaluate if the device will still be able to meet the requirements and consequently if verification and validation activities are required.
Design History File (10)
To demonstrate that you designed and developed your device in accordance with your design plan and applicable requirements, you need to retain the necessary records in your organization.
Risk Management (11)
Risk management as such is not described as a part of the Design Control process but provides key input for design input and the scope of the Design validation. Read our tips for implementing an effective Risk Management process here or learn more about how to gain the benefits of integrating Usability Engineering, Design Control, and Risk Management.
We hope that this article provided you with an overview of how to integrate design control in your Development process saving both time and reducing project risks while developing devices that meet the users’ needs and comply with regulatory expectations.