Jon Speer, Co-Founder and VP of QA/RA, Greenlight Guru08.20.18
If you’re in the medical device industry, you may think design controls are a confusing imposition on your process.
They’re a necessary part of your requirements as a medical device developer and we’ve noticed this area tends to be rife with misconceptions, confusion, and generally making things into a bigger deal than they really need to be. That’s right, design controls don’t need to be a confusing mess!
That said, there are some areas we’d like to address to help medical device engineers navigate their way more easily through design controls requirements. Let’s take a look:
1. Don't Believe the Misconceptions
Probably the biggest misconception about design controls is they equal a heavy load of burdensome documentation. People who believe this also often believe statements like “following good design controls will only slow down our product development," and "design controls will stifle innovation in our business.”
If you believe these statements to be true, then your own design controls processes and practices are out of date and need to be overhauled. There is no need for design controls to be overly burdensome to medical device developers as there are simple ways of keeping yourself compliant.
Design controls are essentially about demonstrating your product is safe, effective, and meets its intended use. You could sum all of this up in an "intended use statement" then use that statement as your pillar. You then have the basis to formulate your user needs, which feed directly into your design outputs. Coming full circle, you then have design validation that ensures your product meets user needs.
In this way, design controls aid product development and innovation. Your goal has to be to create a product meeting that specific “intended use statement” and is proven to be safe and effective. Design controls are the evidence to support your claims that this is so.
A robust design control practice aligns with regulations and allows you to be flexible and innovative. These controls shouldn’t be treated as an afterthought, but should rather align naturally throughout the design process.
2. Keep Your Plan Fluid
A huge mistake we often see is that companies treat design controls as a chore to get out of the way. With regard to a design plan, this is often done at the beginning of a project then locked away. This fails to acknowledge that plans change; in fact, most companies will find themselves making a number of pivots.
Think about how a project is broken into phases (without specifying preference for any particular methodology). There is a beginning, middle, and end. In the beginning, you’re in the discovery phase. You have ideas, perhaps crude prototypes, and an idea for intended use. You don’t know what you don’t know and as such, those things you discover become fuel for your design criteria.
Even keeping intended use as the pillar for your design ideas, you may go through various pivots throughout the middle phase(s) of product development. This is why your design and development plan should be dynamic, developed, and updated throughout each phase of the project. It is a living document, open to change.
It’s also worth clearing up another misconception: There’s often confusion about what a design and development plan actually is. The plan identifies the process you will go through, resources required, and design to be used. It is not just a project schedule. We often see companies are presenting a “plan,” but it is in fact just a schedule, often in the format of a Gantt chart. This might be helpful in terms of keeping product development on track, but it is not the intent of a design plan. The design plan should describe what is actually happening rather than appear as a schedule.
3. Recognize User Needs vs. Design Inputs
Another concept to be aware of is the difference and relationship between user needs and design inputs. There is a great concept of the “user story,” which describes what the user will do with respect to the product, and whether they will be a medical professional, patient, or someone who assists the patient. Think about what the user will do and how they will interact with the product and answer the question: What is important for them? The answers to these questions are what you need to capture as user needs.
A common practice is to describe these stories in vague ways, using terms like “better” or “easier to use.” This is an acceptable and important practice to embrace. Starting with somewhat vague statements as user needs is actually a good method.
How does this relate to design inputs? User stories become the foundation for establishing design inputs. To state this another way, design inputs make the user stories more specific and measurable.
The inputs are, quite simply, the requirements for your device design. They must be objective and stated in a way that can be demonstrated through testing or analysis. You can see where terms such as “better” simply do not cut it when it comes to design inputs.
4. Recognize Design Inputs vs. Design Outputs vs. Design Verification
People get confused as to what design outputs are. They want to capture, through testing, items that prove inputs have been met and show these as design outputs. This is a complete mix-up of terminology.
Let’s break it down:
Another relatively common action taken by medical device developers is thinking they can afford to delay design controls until after a working prototype is established.
The idea is often: “Let’s stay in the research phase for as long as possible. When we’re sure we have a working prototype, we’ll document design controls.”
This is a mistake for a couple of reasons. Firstly, it’s not so easy to play “catch up” on design controls; there are often so many moving parts something is bound to be forgotten. Secondly, you miss the entire point of keeping the design controls.
Through each iteration, you are learning something and your design controls become an important record of learning. You might not nail your prototype the first or even the fourth time around, but you surely learned something with each version. Capture this in documentation so you have a good record of it.
Final Thoughts
Design controls do not have to be the big, imposing task they are often made out to be. In fact, setting them up the right way can encourage innovation and speedy product development, rather than slowing it down.
Establish your design controls early, preferably with a centralized, electronic system that allows access to all who need to be involved. Staying on top of design controls right from prototyping will not only help to keep you compliant, but will help to enhance your learning experience over the course of development.
Jon Speer is the founder and VP of QA/RA at Greenlight Guru, a software company that produces the only modern quality management software solution exclusively for medical device companies. Device makers in more than 250 cities in 26 countries use Greenlight Guru to get safer products to market faster with less risk while ensuring compliance. Speer is a medical device industry veteran with over 18 years of experience, having helped dozens of devices get to market over his career in a variety of roles, including product development, project management, quality, and regulatory. He is also a thought leader, speaker, and regular contributor at numerous leading industry publications.
They’re a necessary part of your requirements as a medical device developer and we’ve noticed this area tends to be rife with misconceptions, confusion, and generally making things into a bigger deal than they really need to be. That’s right, design controls don’t need to be a confusing mess!
That said, there are some areas we’d like to address to help medical device engineers navigate their way more easily through design controls requirements. Let’s take a look:
1. Don't Believe the Misconceptions
Probably the biggest misconception about design controls is they equal a heavy load of burdensome documentation. People who believe this also often believe statements like “following good design controls will only slow down our product development," and "design controls will stifle innovation in our business.”
If you believe these statements to be true, then your own design controls processes and practices are out of date and need to be overhauled. There is no need for design controls to be overly burdensome to medical device developers as there are simple ways of keeping yourself compliant.
Design controls are essentially about demonstrating your product is safe, effective, and meets its intended use. You could sum all of this up in an "intended use statement" then use that statement as your pillar. You then have the basis to formulate your user needs, which feed directly into your design outputs. Coming full circle, you then have design validation that ensures your product meets user needs.
In this way, design controls aid product development and innovation. Your goal has to be to create a product meeting that specific “intended use statement” and is proven to be safe and effective. Design controls are the evidence to support your claims that this is so.
A robust design control practice aligns with regulations and allows you to be flexible and innovative. These controls shouldn’t be treated as an afterthought, but should rather align naturally throughout the design process.
2. Keep Your Plan Fluid
A huge mistake we often see is that companies treat design controls as a chore to get out of the way. With regard to a design plan, this is often done at the beginning of a project then locked away. This fails to acknowledge that plans change; in fact, most companies will find themselves making a number of pivots.
Think about how a project is broken into phases (without specifying preference for any particular methodology). There is a beginning, middle, and end. In the beginning, you’re in the discovery phase. You have ideas, perhaps crude prototypes, and an idea for intended use. You don’t know what you don’t know and as such, those things you discover become fuel for your design criteria.
Even keeping intended use as the pillar for your design ideas, you may go through various pivots throughout the middle phase(s) of product development. This is why your design and development plan should be dynamic, developed, and updated throughout each phase of the project. It is a living document, open to change.
It’s also worth clearing up another misconception: There’s often confusion about what a design and development plan actually is. The plan identifies the process you will go through, resources required, and design to be used. It is not just a project schedule. We often see companies are presenting a “plan,” but it is in fact just a schedule, often in the format of a Gantt chart. This might be helpful in terms of keeping product development on track, but it is not the intent of a design plan. The design plan should describe what is actually happening rather than appear as a schedule.
3. Recognize User Needs vs. Design Inputs
Another concept to be aware of is the difference and relationship between user needs and design inputs. There is a great concept of the “user story,” which describes what the user will do with respect to the product, and whether they will be a medical professional, patient, or someone who assists the patient. Think about what the user will do and how they will interact with the product and answer the question: What is important for them? The answers to these questions are what you need to capture as user needs.
A common practice is to describe these stories in vague ways, using terms like “better” or “easier to use.” This is an acceptable and important practice to embrace. Starting with somewhat vague statements as user needs is actually a good method.
How does this relate to design inputs? User stories become the foundation for establishing design inputs. To state this another way, design inputs make the user stories more specific and measurable.
The inputs are, quite simply, the requirements for your device design. They must be objective and stated in a way that can be demonstrated through testing or analysis. You can see where terms such as “better” simply do not cut it when it comes to design inputs.
4. Recognize Design Inputs vs. Design Outputs vs. Design Verification
People get confused as to what design outputs are. They want to capture, through testing, items that prove inputs have been met and show these as design outputs. This is a complete mix-up of terminology.
Let’s break it down:
- Design inputs: These define all the performance criteria, requirements, and features of your medical device product. As mentioned earlier, they should stem directly from user needs. Good design inputs provide the foundation for a strong and successful medical device.
- Design outputs: We like to think of design outputs as a "recipe" for your medical device. Design outputs consist of all the parts, components, inspection procedures, and other materials or procedures that go into your medical device. They are the documents you would give to someone who has the job of assembling your device.
- Design verification: The goal of design verification is to prove design outputs meet design inputs. It is all of the testing, analysis, and inspections that serve as your proof to demonstrate your medical device has been designed correctly. As you can see from these definitions, people often make the mistake of mixing up design outputs and verification. It might seem like semantics, but it’s important in terms of having your paperwork completed correctly.
Another relatively common action taken by medical device developers is thinking they can afford to delay design controls until after a working prototype is established.
The idea is often: “Let’s stay in the research phase for as long as possible. When we’re sure we have a working prototype, we’ll document design controls.”
This is a mistake for a couple of reasons. Firstly, it’s not so easy to play “catch up” on design controls; there are often so many moving parts something is bound to be forgotten. Secondly, you miss the entire point of keeping the design controls.
Through each iteration, you are learning something and your design controls become an important record of learning. You might not nail your prototype the first or even the fourth time around, but you surely learned something with each version. Capture this in documentation so you have a good record of it.
Final Thoughts
Design controls do not have to be the big, imposing task they are often made out to be. In fact, setting them up the right way can encourage innovation and speedy product development, rather than slowing it down.
Establish your design controls early, preferably with a centralized, electronic system that allows access to all who need to be involved. Staying on top of design controls right from prototyping will not only help to keep you compliant, but will help to enhance your learning experience over the course of development.
Jon Speer is the founder and VP of QA/RA at Greenlight Guru, a software company that produces the only modern quality management software solution exclusively for medical device companies. Device makers in more than 250 cities in 26 countries use Greenlight Guru to get safer products to market faster with less risk while ensuring compliance. Speer is a medical device industry veteran with over 18 years of experience, having helped dozens of devices get to market over his career in a variety of roles, including product development, project management, quality, and regulatory. He is also a thought leader, speaker, and regular contributor at numerous leading industry publications.
