Navigating Medical Device Development: A Hands-on Guide Part 3 - Device Design and Development
In my previous?article, the second part of a series on Navigating Medical Device Development: A Hands-on Guide, we explored how to write an imaginary device's intended use and classify it according to MDR medical device risk classification. In this article, we will go through an introduction to the Device Design and Development Process.
Table of Contents
3. Device Design and Development
Now that I have an idea for a throat diagnosing device, I have conducted some research, tested the idea, and assessed the initial market response. Additionally, I have classified its risk. 'Okay, let's build it,' you thought in your mind. You have also undertaken some initial work on Management Responsibilities, such as quality policy, planning, responsibilities, etc., and have allocated resources effectively, including human power, machines, and infrastructure, for the development of the product.
Now, you have stumbled upon this particular figure (see Figure 1) that you found in your QMS. Initially, you thought you had an idea of the device in your head and a rough drawing of the product, which you showed to the doctors, and that's it – you could start the development. However, when you look at this figure of Design Controls, you realize there is much more involved than you initially thought.
It looks like it starts with User Needs, Design Inputs, Design processes, Design Outputs, and finally, the Medical Device. Ohh well, there are three more blocks: Validation, Verification, and Review.
Waterfall model
After further studies and research, you now realize that this is the so-called waterfall model visualization in the product development lifecycle.
User Needs: This is the first step and involves collecting and documenting the user's needs.
Design Inputs: This step involves analyzing the user needs and creating design inputs, such as:
Design Process: This is the process where you take the design inputs and create the design outputs.
Design Outputs: These are the outputs from the Design Process, and they include:
Medical Device: This is the last blue block where you assemble every part together to create a final product.
All right, you understand it a bit better, but there are 3 more blocks, and you don't know yet what they are doing there. After further research and studies, you now understand the rest.
Validation: This is the process in which you check if the product you developed meets user needs and its intended use. The validation is done by the users of the product, in this case, doctors, not by you or your employees in the company. During the validation, you will understand if the device is safe to use for both patients and users according to the user needs and intended use in the hospital setup and if it is performing accordingly. This could be done through a clinical evaluation.
Verification: On the other hand, one checks if the Design Inputs meet the Design Outputs. For example, the system architecture design is verified by system integration tests, the hardware/software architecture design is verified by hardware/software integration tests, and units are verified by unit verification tests, code reviews, etc. These are done by you and your engineering team.
Reviews: After each stage or at appropriate levels, you also need to conduct a formal review procedure to see if the outputs meet the input requirements for that stage. For example, one may conduct a review after converting the user needs to System requirements to see if all user needs are effectively converted and covered in system requirements as planned. If they are not covered properly, then take necessary corrective steps.
Perfect! Now you understand more about design and development and design controls, but what does it have to do with the waterfall model?
Traditionally, people see Figure 1 as a waterfall process, as shown in Figure 2 below,
领英推荐
where, one can proceed to the next stage only after finishing the previous stage. In this process, the flow of work can be compared to water flowing under gravity. However, after each stage, there is a valve, and it can only flow to the next stage after opening the valve, analogous to the review and approval process. This may be an effective process if you have the best designers at your disposal and you know the user needs perfectly. For example, NASA is said to follow the waterfall process.
Even though the waterfall model has its advantages, such as:
The main criticism against this model is that the user only sees a product after all stages of the design and development are finished. When the user starts to validate it, they may identify some needs for change, and then these change requests have to go through the change request process, design changes, etc., leading to a long wait.
Another problem is that designers won't have a full picture of future problems, and the requirements may not be sufficient enough to capture all potential weaknesses in the design. These weaknesses may only be discovered during the verification or validation phases.
What if one can design and develop a medical device in an iterative way (SPACEX is said to follow iterative methods), where one user need enters the process at a time instead of all user needs at the same time? Fortunately, no regulation (MDR or FDA CFR) enforces you to follow the waterfall model in medical device development.
After a lot of research and study, you tried to understand how you can implement iterative development with the help of an updated Design Control figure (see Figure 3), while still in compliance with the regulations.
Your reasoning now is that initially you don't know all user needs, but you have a subset of user needs. You choose them according to their priority and how important the information is when that particular user need is validated. Then, the priority number 1 user need will go to the next stage, and its requirements and architecture, etc., are designed and reviewed at relevant stages. After limited verification, the partial product will go to the user for partial validation. In this way, you will receive customer feedback faster after each iteration of a single user need, instead of waiting to finish the design for all user needs.
You can incorporate the user feedback and change requests fortunately at the user needs level mostly if they have not gone through the design process yet, or at the design inputs or design outputs. The changes are happening at a very early stage, thanks to the feedback. This method will clarify the needs of the user when they see a piece of an actual device. Other advantages of this iterative method are:
Also, you understand that if you design your throat diagnosing device using such an iterative method, you first create user needs in a way that they can be designed and developed individually. Then, you give them for a partial validation to the user and get feedback. For example, the first priority user need is: 'As a user, I need my device to have a lollipop-shaped end so that the patient will open their mouth easily.
Then you design only this part, create the partial product, and validate it with the user to see if the patient will open their mouth. Of course, there are many other things that need to be considered, like cleanability, sterility, etc., but you got the point. During the validation, the doctor found that the lollipop part is too big for kids. Now you have a problem, documented the feedback, started the change management procedure, etc., but the important point is that you spotted it early on.
After each user needs leaves the Design input part, the next priority user need can enter the Design input stage, and so on. In this way, iterative method design and development can continuously design, continuously integrate (CI), and continuously deploy (CI, partially).
Further research also showed you a more intuitive way to understand the design and development process: the V-model (see Figure 4).
The left side of the "V" represents the decomposition of requirements and the creation of specifications. The right side of the "V" represents the integration of parts and their verification and validation. It shows each stage and its deliverables. For example, the Requirements capture stage generates System requirements deliverables.
Now, you see one more block here, a red block with Risk analysis and Risk controls. What is that? Curious to know more about Risk Management? Wait until the release of the next article.
Congratulations! You have reached the end of this article. I hope you enjoyed reading it, and I hope it has inspired you to learn more about medical device development. Curious to know the rest? especially the Risk Management, wait until the release of the next part and further. If you like this article series, don't forget to subscribe to the newsletter.
If you have any questions or comments, feel free to leave them below. I will be happy to answer them.
Thank you for reading!