I'm currently working on a project for my undergraduate senior design project in which we are creating the prototype for a new medical device. For this project, my team is working our way through the 9 parts of the Design Controls. Currently, we've only gotten through the planning and input stages of the process. In the planning stage, we completed the Design Development Plan in which we layed out the timeline and detailed plans for the project. We are now working on the Design Inputs, and are using the user needs to develop the specific inputs for the project. 

Though we have not worked with most of the parts of the Design Controls yet, they seem very necessary for us to complete the project successfully. 

As an R&D Engineer, I work with a lot of the types of documents that were described in this weeks lecture. For our Design Input Document (DID) we have a document called a Market Specification, which identifies the market requirements (user needs) for the device that is going to be developed. These items translate directly into a Design Output and Design Specification Document (DSD) called the Product Specification. This is where we list the engineering specifications for every item that was listed in the Market Spec. This document was updated regularly while we were in the development phase of the project. Once the design was finalized (at a formal Design Review meeting to end the development phase), we entered into the verification & validation phase. We wrote Design Verification Protocols, and built, conditioned, and tested samples accordingly. After the completion of verification & validation activities, the design was transferred to production via design transfer.

Design Controls are extremely important in medical devices, and it is impossible to work in the medical device industry as an engineer without being involved in design controls. By using design controls and creating a well documented device via the DHF, it is much easier to evaluate design changes over the life of the product. It also provides well documented evidence to FDA auditors that the products that were cleared/approved by the FDA continue to be built according to the design, and shows how any changes to the original design were evaluated and implemented.

This is a very interesting post since I do not have much experience with this topic. I have been involved in validations and the development of laboratories by acquired CLIA and others, but have not had the chance to work in the development of a medical device or the regulatory components that it requires. To answer the question posted about perhaps bypassing or not using one of the 9 parts of design control for a new medical device, I do not think it is possible to do so. All parts are subsequent stages that contribute to the whole presentation and establishment of the new device. Each one providing certain importance to governing agencies regarding the design, validation, risks, and other important parts of the device.

All the 9 are very important, but you can still find projects done without some of them.

- Planning should have breakdown of tasks alongside the people/team responsible for them, a Gantt chart is the best example for it.

- Inputs in other words customer attributes, and user needs.

- Output is a clear description of the product, containing detailed information for production.

Output should be verified against the design inputs.

- Review is a periodic and planned activity undertaken during the design process that helps ensure you are on the right track

- Verification can be said to be the answer for did we design the device right. Its to see if the output meets the intended input requirements.

- Validation can be said to be the answer for did we design the right device. To check the design in real life condition.

- Transfer of a product design into a manufacturing environment

- Changes the modification conducted to the project which can happen any time in the project

- Design History file which have everything

So as you can see all the 9 parts are connected together and depend on each other, and without any of them the project will be missing a lot.

My closest experience working with design controls was when I developed a surgical stapler testing apparatus for my undergraduate senior year capstone project. My team and I implemented the twelve-step engineering design process to effectively develop our idea from concept to product which ultimately covered the same nine phases of design controls as presented in lecture. I believe the nine phases of design controls provides a more general outline of a process to follow than the twelve step engineering design process because much of the initial steps in the twelve step engineering design process can be achieved in the first phase of the design controls process.

I've had experience with design control during my undergrad capstone. I got my B.S. in mechatronics engineering and the capstone had to be electronic with other guidelines. We didn't do the specified documentation presented in this lecture but our report and presentation on consistent with the material needed for design control documentation. It was an automated spice carousel with a build prototype for all four subassemblies. 

I work in R&D Lifecycle Management so our design change projects are an update or change to an existing product, not the development of a new product. However, we still use design controls to run these projects.

1.Planning - In this phase, we fill out a Design Change Notice part 1 (DCN). This template allows us to lay out what the design change will be, its purpose, what will be impacted, how we are going to validate/verify - essentially the plan

2.Input - This is included in the DCN part 1 as well, where we list what existing inputs are changing or what new design inputs are being added to the product

3.Output - Also included in DCN part 1

4.Review - Design reviews are mandatory. Strategies for design verification/validation, process validation, regulatory, bicomp, and sterilization strategies all must be completed before initial design review and referenced in the DCN part 1

DCN part 2 is the execution phase and includes the following:

5.Verification 

6.Validation 

7.Transfer

8.Design Changes

9.Design History File

After learning about design controls in this week’s lecture, looking back at my undergraduate capstone project, I can see these parts were followed even if they were not specifically identified. Each of the nine parts were included in a very similar order. I remember specifically our final report, which in this case would be the equivalent of the design history file, was rather large and time consuming to write. If you were to ask me before this project if all nine parts were necessary, I probably would have said no. With no exposure to design controls, it appears that some parts may be combined into one (input & output, verification & validation). I now realize the importance of having these separate parts.  

I currently work as an R&D Scientist in vaccines, and in our daily processes, design change control and other various IOQ and PQ documents are readily used to modify our robotic machinery that is used in clinical data. Because I work in a clinical setting where everything is micro-scrutinized, it is important to have good documentation and record-keeping and make sure that everything that you do can be traced back to its source. In our lab, when we decide to change the code to one of our machines we must submit a change control for minute design changes, which allows us to implement the change after we prove that it will not change any other processes other than the one we want to change. However, if there is a process change that is deemed substantial, it must go through a Design Change control in which a whole series of tests must be conducted and each scenario and different test cases must be done to ensure that nothing else has been touched and that certain work functions are available with the change. So because of that, it is important I believe to know the different types of documents that are there and when they should be used and to be able to keep track of everything that is done to prevent an audit to come back with an error.